AS112 Nameserver Delegations for IPv6
draft-michaelson-as112-ipv6-02

Abstract

To reduce longterm traffic to the DNS root servers and the IP6.ARPA authoritative servers, the IAB is requested to instruct the IANA to delegate a set of sub-domains of IP6.ARPA to the AS112 Project [RFC6304]. These domains represent IPv6 address prefixes that are not conventionally populated in the global reverse-DNS, including IPv6 prefixes that are not globally scoped and certain prefixes used in an anycast context.

The reverse DNS query load associated with these IPv6 address prefixes appear to have unacceptable scaling consequences as IPv6 uptake increases. By delegating these sub-domains to the AS112 project, the DNS query load can be passed to a distributed sink, reducing the query load on the root servers and the IP6.ARPA authoritative servers.

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 March 10, 2012.

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.

Table of Contents

• 1. Reverse DNS Delegation and Local-Use Addresses
• 2. IANA Considerations
• 3. Security Considerations
• 4. Acknowledgments
• 5. Changes
• 5.1. Changes since the -00 draft
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Reverse DNS Delegation and Local-Use Addresses

The IPv6 Addressing Architecture [RFC4291] and Unique Local IPv6 Unicast Addresses [RFC4193] includes certain address prefixes that are not intended to be uniquely used in the global network as globally-scoped unicast addresses. Such addresses include locally-scoped addresses, certain anycast addresses, and loopback addresses.

While such addresses are not intended to be used in the same context as globally-scoped unicast addresses, their use in various local and global contexts is seen to trigger Domain Name System (DNS) [RFC1034] queries (of the form of "reverse lookups") corresponding to these addresses. Since the addresses concerned generally have local rather than global significance, it is good practice for site administrators to ensure that such queries are answered locally [RFC6303]. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries, and the response to such reverse lookup queries from the global DNS is the "Name Error" RCODE described in [RFC1035], commonly termed "NXDOMAIN".

When the reverse-DNS infrastructure receives a request for un-delegated sub-domains, the point of delegation of the last matched label along the name path to the root receives the query. In the case of the IPv6 reverse delegation structure, this implies that the IP6.ARPA authoritative servers will receive the query load. Because the sub-domain is not delegated, the server is obliged to answer with an NXDOMAIN response. A large number of these DNS queries are repeated, further increasing the DNS query load imposed on the DNS root servers and the IP6.ARPA authoritative servers.

This query load appears to have unacceptable scaling consequences as IPv6 uptake increases. By delegating these sub-domains to the AS112 project [RFC6304], the DNS query load can be passed off to a distributed dedicated server set, reducing the load through the DNS root and on the IP6.ARPA authoritative servers.

2. IANA Considerations

As per the provisions of [RFC3152], this document recommends the IAB to direct IANA to delegate the following IP6.ARPA reverse DNS zones to the AS112 project [RFC6304]:

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa (Unspecified)
                          8.e.f.ip6.arpa (Link-Local Scope)
                          9.e.f.ip6.arpa (Link-Local Scope)
                          a.e.f.ip6.arpa (Link-Local Scope)
                          b.e.f.ip6.arpa (Link-Local Scope)
                          c.e.f.ip6.arpa (Site-Local Scope)
                          d.e.f.ip6.arpa (Site-Local Scope)
                          e.e.f.ip6.arpa (Site-Local Scope)
                          f.e.f.ip6.arpa (Site-Local Scope)
                        1.0.f.f.ip6.arpa (Interface-Local multicast scope)
                        2.0.f.f.ip6.arpa (Link-Local multicast scope)
                        4.0.f.f.ip6.arpa (Admin-Local multicast scope)
                        5.0.f.f.ip6.arpa (Site-Local multicast scope)
                        8.0.f.f.ip6.arpa (Organization-Local multicast scope)
                0.0.0.0.1.0.0.2.ip6.arpa (Teredo)
                8.B.D.0.1.0.0.2.ip6.arpa (Documentation Prefix)

AS112 project servers should add these zones to their configuration, and terminate queries efficiently inside their service infrastructure.

This delegation instruction is subject to further direction in the future from the IAB to IANA, as per the provisions of [RFC3152].

3. Security Considerations

The Security Considerations described in [RFC6304] also apply to local-use IPv6 addresses, and should be considered in the context of the use of these addresses.

DNS queries may well identify the location of deployment of IPv6 enabled equipment in private contexts, particularly when the reverse queries relate to local-use IPv6 addresses. While operators of the DNS reverse servers should respect the privacy of data relating to individual queries made to these reverse address servers, the unintentional leakage of information beyond its intended scope of use and circulation represents a potential threat to the security of a local private network. This direction to delegate these local-use IPv6 reverse address sub-domains does not substantially change the security risks of information leakage from private environments.

4. Acknowledgments

The authors acknowledge the work of Joe Abley and William Maton and the DNSOPS Working Group in preparing the AS112 framework document for delegation of the private use address blocks in IPv4, and have used parts of their AS112 document as a template for these AS112 delegation instructions in IPv6. John Mann also provided much useful feedback.

5. Changes

[Note: This section is not for publication.]

5.1. Changes since the -00 draft

The multicast ranges were stripped back to the subset of scopes which do not have future specific applicability for a reverse-DNS registry under consideration by the multicast community of interest.

mis-labelled Site-Local addresses were renamed (john mann)

6. References

6.1. Normative References

6.2. Informative References

Authors' Addresses