diff --git a/doc/draft/draft-ietf-ipngwg-dns-lookups-03.txt b/doc/draft/draft-ietf-ipngwg-dns-lookups-04.txt similarity index 71% rename from doc/draft/draft-ietf-ipngwg-dns-lookups-03.txt rename to doc/draft/draft-ietf-ipngwg-dns-lookups-04.txt index 3f33e3d912..d23306a396 100644 --- a/doc/draft/draft-ietf-ipngwg-dns-lookups-03.txt +++ b/doc/draft/draft-ietf-ipngwg-dns-lookups-04.txt @@ -1,18 +1,17 @@ - IPng Working Group Matt Crawford Internet Draft Fermilab Christian Huitema Susan Thomson Bellcore - December 15, 1998 - - DNS Extensions to Support IP Version 6 - + May 20, 1999 + DNS Extensions to Support IPv6 Address Aggregation and Renumbering + Status of this Memo - This document is an Internet-Draft. Internet-Drafts are working + 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. @@ -22,50 +21,40 @@ Status of this Memo 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 entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - Distribution of this memo is unlimited. + 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. 1. 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 - in a manner which expedites network renumbering, and updated - definitions of existing query types that return Internet addresses - as part of additional section processing. + 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 domain to hold the top-level delegation - information and a 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. + 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. +Expires November 25, 1999 Crawford et al. [Page 1] - - -Expires June 20, 1999 Crawford et al. [Page 1] - -Internet Draft IPv6 DNS December 15, 1998 - +Internet Draft IPv6 DNS May 20, 1999 2. Introduction - Current support for the storage of Internet addresses in the Domain - Name System (DNS) [DNSCF, DNSIS] cannot easily be extended to - support IPv6 addresses [AARCH] since applications assume that - address queries return 32-bit IPv4 addresses only. In addition, - maintenance of address information in the DNS is one of several + Maintenance of address information in the DNS is one of several obstacles which have prevented site and provider renumbering from - being feasible. - - To support the storage of IPv6 addresses without impeding + 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 documents cited here as + [RENUM]. To support the storage of IPv6 addresses without impeding renumbering we define the following extensions. o A new resource record type, "A6", is defined to map a domain @@ -82,10 +71,10 @@ Internet Draft IPv6 DNS December 15, 1998 o A new prefix-delegation method is defined, relying on new DNS features [BITLBL, DNAME]. - The changes are designed to be compatible with existing - applications. 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]. + 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 and a departure from current implementation practices. The changes @@ -103,17 +92,12 @@ Internet Draft IPv6 DNS December 15, 1998 "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 - - - -Expires June 20, 1999 Crawford et al. [Page 2] - -Internet Draft IPv6 DNS December 15, 1998 - - believed that compliance with the suggestion has tangible benefits in most instances. +Expires November 25, 1999 Crawford et al. [Page 2] + +Internet Draft IPv6 DNS May 20, 1999 3. Overview @@ -121,7 +105,6 @@ Internet Draft IPv6 DNS December 15, 1998 of IPv6 addresses and for lookups based on IPv6 address, including those defined here and elsewhere. - 3.1. Name-to-Address Lookup IPv6 addresses are stored in one or more A6 resource records. A @@ -143,7 +126,6 @@ Internet Draft IPv6 DNS December 15, 1998 address(es) cannot be directly verified. The A6 records which contributed to the address(es) may of course be verified if signed. - 3.2. Underlying Mechanisms for Reverse Lookups This section describes the new DNS features which this document @@ -151,7 +133,6 @@ Internet Draft IPv6 DNS December 15, 1998 features. The reader is directed to the referenced documents for more details on each. - 3.2.1. Delegation on Arbitrary Boundaries This new scheme for reverse lookups relies on a new type of DNS @@ -160,16 +141,14 @@ Internet Draft IPv6 DNS December 15, 1998 hierarchical sequence of one-bit domain labels. Resource records can thereby be stored on arbitrary bit-boundaries. - - -Expires June 20, 1999 Crawford et al. [Page 3] - -Internet Draft IPv6 DNS December 15, 1998 - - Examples in section 6 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 + +Expires November 25, 1999 Crawford et al. [Page 3] + +Internet Draft IPv6 DNS May 20, 1999 + and a sequence of hexadecimal digits is enclosed between "\[" and "]". The bits denoted by the digits represent a sequence of one-bit domain labels ordered from most to least significant. (This is the @@ -193,7 +172,6 @@ Internet Draft IPv6 DNS December 15, 1998 Note that bits are left-justified in a hexadecimal string. - 3.2.2. Reusable Zones DNS address space delegation is implemented not by zone cuts and NS @@ -210,27 +188,16 @@ Internet Draft IPv6 DNS December 15, 1998 which will cause it to look for a.b.c.w.xy. - - - - - - - - -Expires June 20, 1999 Crawford et al. [Page 4] - -Internet Draft IPv6 DNS December 15, 1998 - - 4. Specifications - 4.1. The A6 Record Type The A6 record type is specific to the IN (Internet) class and has type number 38 (decimal). +Expires November 25, 1999 Crawford et al. [Page 4] + +Internet Draft IPv6 DNS May 20, 1999 4.1.1. Format @@ -241,7 +208,6 @@ Internet Draft IPv6 DNS December 15, 1998 | (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. @@ -249,11 +215,12 @@ Internet Draft IPv6 DNS December 15, 1998 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. + 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. This name - MUST NOT be compressed unless some future specification permits - it, and then possibly only under certain circumstances. + 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 @@ -263,33 +230,29 @@ Internet Draft IPv6 DNS December 15, 1998 other A6 records have all the insignificant trailing bits in its address suffix field set to zero. - 4.1.2. Processing A query with QTYPE=A6 causes type A and type AAAA additional section processing for the QNAME, and type A6 and type NS additional section - processing for the DNS name, if present, in its RDATA field. When - and if the type AAAA record becomes deprecated, the type AAAA - additional section processing for type A6 queries SHOULD be omitted - - - -Expires June 20, 1999 Crawford et al. [Page 5] - -Internet Draft IPv6 DNS December 15, 1998 - - - from new implementations of this specification. + processing for the DNS names, if any, in the RDATA field of the A6 + records in the answer section. When and if the type AAAA record + becomes deprecated, the type AAAA additional section processing for + type A6 queries SHOULD be omitted from new implementations of this + specification. It is an error for a A6 record with prefix length L1 > 0 to refer to a domain name which owns a 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 signalling an error if addresses can still be formed from + +Expires November 25, 1999 Crawford et al. [Page 5] + +Internet Draft IPv6 DNS May 20, 1999 + valid A6 records, but it is SUGGESTED that zone maintainers from time to time check all the A6 records their zones reference. - 4.1.3. Textual Representation The textual representation of the RDATA portion of the A6 resource @@ -299,8 +262,9 @@ Internet Draft IPv6 DNS December 15, 1998 o A prefix length, represented as a decimal number between 0 and 128 inclusive, - o the textual representation of the host's IPv6 address as defined - in [AARCH], or a suffix of that address, and + 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. @@ -310,7 +274,6 @@ Internet Draft IPv6 DNS December 15, 1998 either implicitly (through the :: notation) or explicitly, as specified in section 4.1.1. - 4.1.4. Name Resolution Procedure To obtain the IPv6 address or addresses which belong to a given @@ -326,21 +289,17 @@ Internet Draft IPv6 DNS December 15, 1998 records beginning at that hostname, discarding records which have invalid prefix lengths as defined in section 4.1.2. - - - - -Expires June 20, 1999 Crawford et al. [Page 6] - -Internet Draft IPv6 DNS December 15, 1998 - - 4.2. Zone Structure for Reverse Lookups Very little of the new scheme's data actually appears under IP6.INT; only the first level of delegation needs to be under that domain. More levels of delegation could be placed under IP6.INT if some top-level delegations were done via NS records instead of DNAME + +Expires November 25, 1999 Crawford et al. [Page 6] + +Internet Draft IPv6 DNS May 20, 1999 + records, but this would incur some cost in renumbering ease at the level of TLAs [AGGR]. Therefore, it is declared here that all address space delegations SHOULD be done by the DNAME mechanism @@ -366,7 +325,6 @@ Internet Draft IPv6 DNS December 15, 1998 returned, the resolver MUST handle returned DNAME records as specified in [DNAME] and iterate. - 5. Modifications to Existing Query Types All existing query types that perform type A additional section @@ -378,19 +336,10 @@ Internet Draft IPv6 DNS December 15, 1998 relevant A6 records available locally to the additional section of a response when processing any one of the above queries. - 6. Usage Illustrations This section provides examples of use of the mechanisms defined in the previous section. All addresses and domains mentioned here are - - - -Expires June 20, 1999 Crawford et al. [Page 7] - -Internet Draft IPv6 DNS December 15, 1998 - - 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. @@ -398,6 +347,9 @@ Internet Draft IPv6 DNS December 15, 1998 Use of the IPv6 aggregatable address format [AGGR] is assumed in the examples. +Expires November 25, 1999 Crawford et al. [Page 7] + +Internet Draft IPv6 DNS May 20, 1999 6.1. A6 Record Chains @@ -432,21 +384,13 @@ Internet Draft IPv6 DNS December 15, 1998 o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 +6.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 - - - - - -Expires June 20, 1999 Crawford et al. [Page 8] - -Internet Draft IPv6 DNS December 15, 1998 - - following records would then appear in X's DNS. $ORIGIN X.EXAMPLE. @@ -455,6 +399,10 @@ Internet Draft IPv6 DNS December 15, 1998 IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. +Expires November 25, 1999 Crawford et al. [Page 8] + +Internet Draft IPv6 DNS May 20, 1999 + And elsewhere there would appear SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. @@ -472,6 +420,88 @@ Internet Draft IPv6 DNS December 15, 1998 D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: +6.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. + +Expires November 25, 1999 Crawford et al. [Page 9] + +Internet Draft IPv6 DNS May 20, 1999 + + $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. + +Expires November 25, 1999 Crawford et al. [Page 10] + +Internet Draft IPv6 DNS May 20, 1999 + +6.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 @@ -495,14 +525,6 @@ Internet Draft IPv6 DNS December 15, 1998 between themselves. Fifth, that the upward prefix referral chain topped out at - - - -Expires June 20, 1999 Crawford et al. [Page 9] - -Internet Draft IPv6 DNS December 15, 1998 - - ALPHA-TLA.ORG. There could have been another level which assigned the TLA values and holds A6 records containing those bits. @@ -518,20 +540,22 @@ Internet Draft IPv6 DNS December 15, 1998 IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. and so on. - - Or the higher-level entity could hold both sorts of A6 records and - allow the lower-level entity to choose to record a copy of the - delegated bits or refer to the higher-level entity's copy. But the - general rule of avoiding data duplication suggests that the proper - place to store assigned values is with the entity that assigned - them. + 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 + +Expires November 25, 1999 Crawford et al. [Page 11] + +Internet Draft IPv6 DNS May 20, 1999 + maintainer to forego the renumbering support afforded by the chaning of A6 records and to record entire IPv6 addresses within one zone file. - 6.2. Reverse Mapping Zones Supposing that address space assignments in the TLAs with Format @@ -548,17 +572,6 @@ Internet Draft IPv6 DNS December 15, 1998 reflect the eight reserved bits in the current aggregatable global unicast addresses format [AGGR]. - - - - - - -Expires June 20, 1999 Crawford et al. [Page 10] - -Internet Draft IPv6 DNS December 15, 1998 - - 6.2.1. The TLA level ALPHA-TLA's assignments to network providers C, D and E are @@ -568,8 +581,6 @@ Internet Draft IPv6 DNS December 15, 1998 \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. - - 6.2.2. The ISP level The providers A through E carry the following delegation information @@ -585,6 +596,9 @@ Internet Draft IPv6 DNS December 15, 1998 DNAME record. In those cases, one zone is being used to map multiple prefixes. +Expires November 25, 1999 Crawford et al. [Page 12] + +Internet Draft IPv6 DNS May 20, 1999 6.2.3. The Site Level @@ -603,18 +617,6 @@ Internet Draft IPv6 DNS December 15, 1998 zone, it will always be possible to keep the forward and reverse definition data for each prefix in one zone. - - - - - - - -Expires June 20, 1999 Crawford et al. [Page 11] - -Internet Draft IPv6 DNS December 15, 1998 - - 6.3. Lookups A DNS resolver looking for a hostname for the address @@ -625,6 +627,10 @@ Internet Draft IPv6 DNS December 15, 1998 information cached, the sequence of queried names and responses would be (all with QCLASS=IN, QTYPE=PTR): +Expires November 25, 1999 Crawford et al. [Page 13] + +Internet Draft IPv6 DNS May 20, 1999 + To a server for IP6.INT: QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT. @@ -662,15 +668,6 @@ Internet Draft IPv6 DNS December 15, 1998 within the TTL of the final PTR record, that record would not have to be fetched again. - - - - -Expires June 20, 1999 Crawford et al. [Page 12] - -Internet Draft IPv6 DNS December 15, 1998 - - 6.4. Deployment Note In the illustrations in section 6.1, hierarchically adjacent @@ -680,13 +677,17 @@ Internet Draft IPv6 DNS December 15, 1998 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 + +Expires November 25, 1999 Crawford et al. [Page 14] + +Internet Draft IPv6 DNS May 20, 1999 + 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. - 7. Transition from AAAA Records Administrators of zones which contain A6 records can easily @@ -712,78 +713,72 @@ Internet Draft IPv6 DNS December 15, 1998 synthesize AAAA records from A6 records in response to clients' AAAA queries. - 8. 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 - - - -Expires June 20, 1999 Crawford et al. [Page 13] - -Internet Draft IPv6 DNS December 15, 1998 - - records. However, just as with IPv4's IN-ADDR.ARPA, authentication of data in the reverse zones is not equivalent to authentication of any forward data. - 9. Acknowledgments The authors would like to thank the following persons for valuable - discussions and reviews: Jim Bound, Steve Deering, Robert Elz, Bob - Fink, Olafur Gudmundsson, Bob Hinden, Bill Manning, Mike O'Dell and - Ken Powell. + discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, +Expires November 25, 1999 Crawford et al. [Page 15] + +Internet Draft IPv6 DNS May 20, 1999 + + Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Robert + Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden, Bill + Manning, Keith Moore, Thomas Narten, Erik Nordmark, Mike O'Dell and + Ken Powell. 10. References + [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373. - [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373. - - [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 - Aggregatable Global Unicast Address Format". RFC 2374. + [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable + Global Unicast Address Format". RFC 2374. [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", - currently draft-ietf-dnsind-binary-labels-03.txt. + currently draft-ietf-dnsind-binary-labels-03.txt. - [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", - currently draft-ietf-dnsind-dname-00.txt. + [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", currently + draft-ietf-dnsind-dname-00.txt. - [DNSCF] Mockapetris, P. V., "Domain names - concepts and - facilities", RFC 1034. + [DNSCF] Mockapetris, P. V., "Domain names - concepts and + facilities", RFC 1034. - [DNSIS] Mockapetris, P. V., "Domain names - implementation and - specification", RFC 1035. + [DNSIS] Mockapetris, P. V., "Domain names - implementation and + specification", RFC 1035. [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System - Security Extensions", RFC 2065. + Security Extensions", RFC 2065. - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119. + [KWORD] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119. - [LOCOMP] Koch, P., "A New Scheme for the Compression of Domain - Names", currently draft-ietf-dnsind-local-compression- - 01.txt. + [RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC + 1900. - [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for + Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: + Why would I want it and what is it anyway?", RFC 2071. + Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address + Behaviour Today", RFC 2101. + [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for +Expires November 25, 1999 Crawford et al. [Page 16] +Internet Draft IPv6 DNS May 20, 1999 - -Expires June 20, 1999 Crawford et al. [Page 14] - -Internet Draft IPv6 DNS December 15, 1998 - - - IPv6 Hosts and Routers", RFC 1933. + IPv6 Hosts and Routers", RFC 1933. 11. Authors' Addresses @@ -797,42 +792,4 @@ Internet Draft IPv6 DNS December 15, 1998 +1 630 840-3461 +1 201 829-4266 +1 201 829-4514 crawdad@fnal.gov huitema@bellcore.com set@bellcore.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires June 20, 1999 Crawford et al. [Page 15] - +Expires November 25, 1999 Crawford et al. [Page 17]