IPng Working Group Matt Crawford Internet Draft Fermilab Christian Huitema Susan Thomson Bellcore December 15, 1998 DNS Extensions to Support IP Version 6 Status of this Memo This document is an Internet-Draft. 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 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. 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. 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. Expires June 20, 1999 Crawford et al. [Page 1] Internet Draft IPv6 DNS December 15, 1998 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 obstacles which have prevented site and provider renumbering from being feasible. 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 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.INT, 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 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]. This memo proposes a replacement for the specification in RFC 1886 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 have automatically-genrerated AAAA records 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 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. 3. 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. 3.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 multiples 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 [DNSSEC] of the returned 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 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. 3.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 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 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 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.INT. \[x0A0020FFFE812B32/64].\[x0009/16]. \[x07C00040/32].\[xFFF0/13].\[x2/3].IP6.INT. 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 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. 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). 4.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. 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. 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. 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. 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 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 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 the host's IPv6 address as defined in [AARCH], or a suffix of that address, and 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 4.1.1. 4.1.4. Name Resolution Procedure To obtain the IPv6 address or addresses which belong to a given hostname, a DNS client MUST obtain one or more complete chains of A6 records, each chain beginning with a record owned by the given hostname 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 which validly covers that position, as indicated by the prefix length. The set of all IPv6 records for the given hostname comprises the addresses formed from all complete chains of A6 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 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 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.INT". 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 iterate. 5. 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 both type A and type A6 additional section processing. These new definitions mean that a name server may add any relevant IPv4 addresses and any 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. Use of the IPv6 aggregatable address format [AGGR] is assumed in the examples. 6.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 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. 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. 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:: 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 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. 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 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. It is possible, but not necessarily recommended, for a zone 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 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.INT zone would include $ORIGIN IP6.INT. \[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]. 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 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. 6.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. 6.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. $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. 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 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.INT, 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.INT: QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT. Answer: \[x234500/24].IP6.INT. 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. 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. 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 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. 7. Transition from AAAA 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 4.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 records If the zone is secure [DNSSEC], the generated AAAA records SHOULD 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. A server providing recursive service MAY be configurable to 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. 10. References [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. [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", currently draft-ietf-dnsind-binary-labels-03.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. [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. [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. [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for Expires June 20, 1999 Crawford et al. [Page 14] Internet Draft IPv6 DNS December 15, 1998 IPv6 Hosts and Routers", RFC 1933. 11. Authors' Addresses Matt Crawford Christian Huitema Susan Thomson Fermilab Bellcore Bellcore MS 368 MCC 1J236B MCC 1C259B PO Box 500 445 South Street 445 South Street Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960 USA USA USA +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]