Network Working Group Keith Moore Internet-Draft University of Tennessee 14 July 2000 Expires: 14 January 2001 6to4 and DNS draft-moore-6to4-dns-00.txt This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments regarding this internet-draft should be sent to the mailing list of the IETF ngtrans working group. Refer to the IETF web site at http://www.ietf.org/ for current contact information for IETF working groups. Abstract This memo discusses several potential mechanisms for locating the DNS servers which provide "reverse address lookup" of 6to4 addresses. Please note that this is a preliminary draft which only attempts to outline possible means of solving the problem, for purpose of discussion. This version of the proposal is NOT rigorously specified, and the author does not claim significant DNS expertise. Nevertheless, it is hoped that the proposal is significantly detailed to allow reviewers to make a first-order assessment of its viability. The assistance of a DNS expert in drafting future revisions of this proposal would be most welcome. Moore Expires 14 January 2001 [Page 1]
6to4 and DNS INTERNET-DRAFT 14 July 2000 1. Introduction 6to4 [1] defines a mechanism for allowing sites to communicate using IPv6 over the public IPv4 Internet. It does so by assigning a block of IPv6 addresses corresponding to any "public" (globally-scoped) IPv4 address, and a means of tunneling IPv6 traffic destined for such addresses over the IPv4 Internet. In this way, any site which is connected to the IPv4 Internet and which has at least one global IPv4 address assigned to it, can communicate with IPv6. The advantage of 6to4 is that it decouples deployment of IPv6 by the core of the network (e.g. Internet Service Providers or ISPs) from deployment of IPv6 at the edges (e.g. customer sites), allowing each site or ISP to deploy IPv6 support in its own time frame according to its own priorities. With 6to4, the edges may communicate with one another using IPv6 even if one or more of their ISPs do not yet provide native IPv6 service. In addition, the principal cost of the 6to4 transition mechanism is borne by those who benefit from it. However, the ability to perform so-called "reverse address lookups" (IP address to domain name lookups) in DNS requires that there be a delegation path corresponding to the IP address being queried, from the DNS root to the DNS server which provides PTR records for that IP address. Under normal circumstances, the necessary DNS servers and records for IPv6 reverse lookups would be maintained by the each organization to which an address block is delegated; the delegation path of DNS records reflects the delegation of address blocks themselves. For IPv6 addresses beginning with the 6to4 address prefix, the DNS records would need to reflect IPv4 address delegation, and might not be present for a 6to4 site whose ISP did not yet support IPv6 in any form. This memo discusses several potential mechanisms for locating the DNS servers which are assumed to provide "reverse address lookup" of 6to4 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. Design Goals An ideal solution to this problem would have several characteristics: - Minimal impact on existing software and operations. - Minimal effort in deployment of DNS support. Moore Expires 14 January 2001 [Page 2]
6to4 and DNS INTERNET-DRAFT 14 July 2000 - Costs borne primarily by those who immediately benefit. - Does not adversely affect security of DNS queries. - Any assumptions made by client or server software as to the location of authoritative DNS server(s) for reverse lookup of a 6to4 address, are made only if no explicit referral information is present. 3. Possible Solutions A fundamental assumption made in all of these cases is that the default DNS server(s) for reverse lookup of a 6to4 address are the same servers that are responsible for reverse lookup of the corresponding IPv4 address. In effect, if there is a NS resource record that refers reverse queries for a portion of IPv4 address space space to some set of DNS servers, we want to behave (in the absence of explicit records to the contrary) as if there is similar NS record for the portion of IPv6 address space corresponding to those IPv4 addresses. More formally, for every resource record of the form: {address-bits}.IN-ADDR.ARPA. NS some-domain.example.com. we want to have the effect of also having a resource record of the form: {address-bits}.[x2002].IP6.ARPA. NS some-domain.example.com. unless the lookup for the IPv6 address can be fulfilled by explicit (NS or DNAME) resource records. The following sections discuss various ways of producing the effect. The NS records so generated or assumed (by whatever means) are termed "pseudo-records" to distinguish them from explicitly-supplied NS records. In all cases, the actual PTR records for 6to4 addresses are explicitly maintained by the site to which that portion of 6to4 space is assigned (i.e. the site to whom the corresponding portion of IPv4 space is assigned). This proposal never makes assumptions about the mapping between specific 6to4 addresses and specific host names. Note that due to the different ways of representing {address-bits} in DNS labels between IPv4 and IPv6, and the different ways of referring queries in each address space, a transformation (to be specified later) will be required. The TTLs of the NS pseudo-records so generated should be no larger than those of the NS records from which they were derived; in some cases it may be desirable to make them smaller. Moore Expires 14 January 2001 [Page 3]
6to4 and DNS INTERNET-DRAFT 14 July 2000 Note also that this proposal uses NS records, rather than DNAME records [2], for query referral. This is done because it seems undesirable for any automatically generated resource record, or a resource record which is assumed by a third party, to make assumptions about a different organization's domain name space. In other words, while it might seem fairly safe to say "If there are PTR resource records for an address in this portion of 6to4 space, they will be found on the same servers as the PTR records for the corresponding portions of IPv4 space" but not to say "If there are PTR records for an address in this portion of 6to4 space, those records will be named after the DNS name(s) of the server(s) used for the same portion of IPv4 space". Sites which have multiple IPv4 address blocks and which wish to run "multihomed 6to4" may still do so by installing their own DNAME records. That is, if an organization is assigned {IPv4-prefix-1} and {IPv4-prefix-2}, it may still maintain the address-to-name mappings of its 6to4 hosts in a single DNS zone, by creating DNAME records of the form: {IPv4-prefix-1}.[x2002].IP6.ARPA DNAME ip6dns.example.com. {IPv4-prefix-2}.[x2002].IP6.ARPA DNAME ip6dns.example.com. on the DNS servers which handle its IPv4 address lookups. A similar technique can be used to aid migration of a site from 6to4 to native IPv6 addresses, provided that the "locally assigned" bits of each 6to4 address will also fit within the space remaining after the "native" pre- fix. The following paragraphs detail several possible techniques which might address the problem. They are not mutually-exclusive; it is possible to employ more than of these techniques. Some of them are less attractive than others. At present the purpose of this document is to outline several possible approaches, and serve as a focal point of discussion, rather than to categorically recommend any particular approach. 3.1. No Change To Any Server Software This technique makes no changes to any DNS client or server software. Rather, it expects that the root servers, ISPs DNS servers, and the DNS servers of other organizations which delegate IPv4 address space, will be populated with similar NS records which refer address lookup queries from 6to4 space. Unless and until the assignee of the IPv4 address requested that IPv6 queries be referred to different servers (i.e. that new DNAME or NS RRs be installed), any changes made to the NS records for IPv4 addresses would also need to be reflected in the corresponding NS records for IPv6 Moore Expires 14 January 2001 [Page 4]
6to4 and DNS INTERNET-DRAFT 14 July 2000 addresses in 6to4 space. As stated above, this technique requires no software changes to either DNS server or client software. However, it would certainly require changes to the software used by registries, ISPs, and other networks, to maintain the DNS records needed to provide reverse address lookups. This technique avoids kludges to DNS software but is assumed to be difficult to deploy, as it requires several different organizations to explicitly support 6to4. 3.2. Pseudo-records generated by DNS servers for the IPv4 zones In this technique, the authoritative DNS servers for IN-ADDR.ARPA and its subdomains are modified to return "psuedo-records" for any query of type PTR or NS which matches a name of the form "{something}.[x2002].IP6.ARPA". In particular, - if the server has explicit records matching the label of a PTR query, those records are returned and no pseudo-records are returned; - if the server has explicit NS records matching the label or a suffix of the label of an NS or PTR query, those records are returned and no pseudo-records are returned; - otherwise, if the server has NS records matching {something}.IN- ADDR.ARPA, or matching any IPv4 address prefix of {something}.IN- ADDR.ARPA, pseudo-NS records corresponding to the longest matching prefixes will be returned. The pseudo-records so returned will be marked authoritative, and their TTLs will be no larger than the TTLs of the explicit records from which the pseudo-records were derived. This technique is assumed to be somewhat easier to deploy than the previous one, because it automates the generation of the pseudo-records and avoids the need for each organization that delegates IPv4 space to change its DNS maintenance procedures. However, it still requires changes to DNS servers, and it requires those organizations to upgrade their DNS servers to include those changes, before the change will be useful. Moore Expires 14 January 2001 [Page 5]
6to4 and DNS INTERNET-DRAFT 14 July 2000 3.3. Pseudo-records generated by DNS resolvers In this technique, DNS servers which act as resolvers behave as if pseudo-records had been returned to them when some kinds of queries fail. In some cases they may return pseudo-records when a query fails. When such a resolver received a PTR or NS query for a label that had a [x2002].IP6.ARPA suffix, it would first attempt to satisfy that query from its cache, or failing that, by forwarding the query to an upstream server. If that query failed due to a "no such domain" error, the resolver would then attempt to find the server for the {something}.[x2002].IP6.ARPA label by issuing an NS query for {something}.IN-ADDR.ARPA. If the original query was for PTR records, and one or more NS records were found for {something}.IN-ADDR.ARPA, the resolver would then forward the original query for {something}.[x2002].IP6.ARPA to one or more of those servers, and return the results from one of the forwarded queries if any were successful. If the original query was for NS records, and one or more NS records were found for {something}.IN-ADDR.ARPA, the resolver would then return the pseudo-records corresponding to the IN-ADDR.ARPA domains. Those pseudo-records would NOT be marked as authoritative, and the resolver would NOT cache those records. Note that while the DNS resolver effectively behaves as if pseudo- records had been returned to it by other servers, it MUST NOT cache those pseudo-records. However, it MAY cache the actual NS or PTR records returned by those servers. This technique requires changes to DNS resolver software, and requires that sites using IPv6 and wishing to communicate with 6to4 sites, upgrade their DNS resolvers to include this change. 3.4 Pseudo-records generated by DNS query libraries In this technique, the run-time library used on a host by applications is modified to process DNS queries in the following manner: If the query is of type PTR or NS, and the label queried has a suffix of [x2002].IP6.ARPA, or if the query is otherwise intended to perform an address-to-name lookup, and the address being looked up is a 6to4 address, an attempt is first made to look up the address via normal means. If this attempt failed, a query is made (internally) for NS records corresponding to the embedded IPv4 address. If this secondary query is successful, the original DNS query for the 6to4 address is re- issued to the servers which are authoritative for that IPv4 address; the Moore Expires 14 January 2001 [Page 6]
6to4 and DNS INTERNET-DRAFT 14 July 2000 result is determined from the response to that query. This technique requires changes to DNS query libraries (or applications), and requires that hosts and/or applications using IPv6, and which wish to communicate with hosts and/or applications at 6to4 sites, upgrade their DNS libraries to include this change. 4. Security Considerations Pseudo-records that are automatically generated cannot be signed by DNSSEC, even if the explicit records from which the pseudo-records are derived are signed. Since explicit records take precedence over pseudo- records, a host or application SHOULD NOT trust a signed NS record referring a query for some portion of IPv4 space as evidence of authoritative referral to the corresponding portion of 6to4 space unless it has evidence that there are no explicit records present for that portion of 6to4 space. 5. Author's Address Keith Moore University of Tennessee, Knoxville 104 Ayres Hall Knoxville TN, 37996-1301 USA email: moore@cs.utk.edu 6. References Additional references will be supplied in a later version. [1]. draft-ietf-ngtrans-6to4-06.txt, work in progress. [2]. draft-ietf-ipngwg-dns-lookups-08.txt, work in progress. Moore Expires 14 January 2001 [Page 7]