Sunset4 Working Group D. Song Internet-Draft BII Intended status: Standards Track D. Ma Expires: January 23, 2015 ZDNS July 22, 2014 Considerations on IPv6-only DNS draft-davey-sunset4-ipv6onlydns-00 Abstract Domain name system (DNS)is a key Internet infrastructure service connecting the IP layer and the identifier layer of Internet. This memo describe the behavior and inherent limitation of DNS in IPv4 and dual-stack environment. To ease the problem as well as bringing some incentive to turn off IPv4 as soon as possible, this memo is intended to introduce potential solutions to make some changes on DNS protocol and operation practice in the IPv6 only network. 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 January 23, 2015. Copyright Notice Copyright (c) 2014 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 Song & Ma Expires January 23, 2015 [Page 1] Internet-Draft IPv6-only DNS July 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2.1. IPv4 Fallback Problem . . . . . . . . . . . . . . . . . . 3 2.2. DNS Referral Reaponse Size Issues . . . . . . . . . . . . 3 2.3. Scalability on Root Server System . . . . . . . . . . . . 3 3. Proposed Ideas . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Separate IPv6 and IPv4 in DNS . . . . . . . . . . . . . . 4 3.2. IPv6-aware DNS Referral Response Mechanism . . . . . . . 4 3.3. Enlargement of UDP Minimum Size parameter in IPv6-only Network . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Introduce more IPv6-only Root Server . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Domain name system (DNS) is a key Internet infrastructure service connecting the IP layer and the identifier layer. It works well for many years with high scalability to support the Internet explosion in IPv4 environment with its original design. However, when new technologies such as IPv6, DNSSEC as well as complicated and unpredictable mid-box/end system implementation introduced to the Internet, the original design of DNS need to be reexamined to meet new requirements. This memo describes the behavior and inherent limitation of DNS focusing on networking aspect. Along with Internet development, for example in IPv6 transition, some problems emerge and seems hard to be solved. To ease the problem as well as bringing some incentive to turn off IPv4 as soon as possible, this memo is intended to introduce potential solutions to make some changes on DNS protocol and fixed operation practice in the newly developed IPv6 only network. Note that this memo is written with a joint background of global IPv6 transition. Although significant growth of IPv6 traffic is observed in some pioneer companies [1] and regions, the low IPv6 penetration worldwide indicates that IPv6 is far from fully launched. So to accelerate the transition to a fully connected IPv6 network as soon as possible is one of the requirement this memo want to meet. Song & Ma Expires January 23, 2015 [Page 2] Internet-Draft IPv6-only DNS July 2014 Note that some problem and discussion in this memo are not exclusive in IPv6 context. The authors hope new DNS protocol or changes takes full consideration of IPv6-only capability. So the discussion in this memo is in line with the topics both in IETF dnsop and sunset4 WG. 2. Problem Statement There are three aspects about inherent limitation of DNS in IPv4 and dual-stack environment: 2.1. IPv4 Fallback Problem When IPv6 is introduce to DNS RFC4772[2], DNS keep the independence of DNS transport protocol and DNS records. Based on this setting, it is feasible to cause IPv4 fallback problem RFC6555 [3] when IPv4-only capable clients use IPv4 connection to query AAAA RR and launch IPv6 connection firstly with bad experience afterwards. It may be caused by the diversity or misconfiguration of end system and stub network. But, it makes little sense for IPv4-only capable users to see IPv6 Internet. In addition, when people decide to turn off IPv4 in their network, how global or local DNS system adjust to the new setting is not discussed fully yet. 2.2. DNS Referral Reaponse Size Issues This issue is fully described by [4]. Due to the required minimum IP reassembly limit for IPv4, the original DNS standard limited the UDP message size to 512 octets which became ahistorical and practical hard DNS protocol limit, no matter new protocol like IPv6 and EDNS0 RFC6891 [5] introduced. This limit presents some special problems for zones wishing to (1) add more authority servers or (2) advertise the IPv6 addresses of newly updated dual-stack NS name servers, (3) use DNSSEC. 2.3. Scalability on Root Server System Due to the DNS Referral Response Size Issues, in the early day of Internet, the number of root server is limited to 13. Due to various reasons, this 13 pattern hinder the wide distribution of root zone file as a crucial Internet infrastructure services which is ought to be pervasive. In addition, the uneven distribution of Root server operators also cause heated dispute and distrust. The problems above is being discussed and solved case by case in IETF community, such as happy eyeballs [3] for IPv4 fall back and EDNS0 [5] for DNS hard limit, Universal anycast [6] for scalability of Root server system. But each of them needs time and effort for wide Song & Ma Expires January 23, 2015 [Page 3] Internet-Draft IPv6-only DNS July 2014 separate acceptance and deployment. Instead, this memo trying to answer the question by the virtue of IPv6 along the wave of IPv6 development, especially in IPv6-only context. 3. Proposed Ideas This section is intended to explore the feasibility to make some changes on DNS protocol and operation practice in the network turning off IPv4 or newly developed IPv6 only network. Specific solutions are proposed as following to answer the problem listed in section 2. 3.1. Separate IPv6 and IPv4 in DNS To counter the problem describe in section 2.1, one possible approach is to logically separateIPv6 and IPv4 in DNS RR, which means query from IPv4 connection get response with only IPv4-related RR information, vice versa. There is an alternative is to donate a large amount of public DNS servers with only IPv6 connectivity (indicated by the presence of AAAA records) and no IPv4 connectivity (as indicated by the absence of A records) which only server the IPv6 users. This proposal will introduce new kinds of split-view of DNS dependent on transport protocol. Analysis and test should be done on the coordination between IPv4/IPv6 DNS split-view and DNSSEC deployment with two different content of zone files in the DNS system which may introduce complication involving different ZSK for each zone file. 3.2. IPv6-aware DNS Referral Response Mechanism In section 2.2, due to the limitation of DNS referral response size, it may occur that when new NS server updated to IPv6, the address cannot be carry in the referral response in the first place without EDNS0 support. It may deliver the incomplete view of IPv6 Internet to IPv6 only recursive server and IPv6-only users. For example, the Root zone and any zones with more than 9-10 authority server may face the problem. One intuitive thinking is that if the query is on IPv6 connection, the IPv6 addresses should be carried with high priority in DNS response if there is not enough room for all the NS RR. For example, as a key internet public services, IPv6 addresses of root name servers will be entirely contained in the referral response over IPv4 address information in dual-stack environment. Song & Ma Expires January 23, 2015 [Page 4] Internet-Draft IPv6-only DNS July 2014 3.3. Enlargement of UDP Minimum Size parameter in IPv6-only Network The fundamental problem in section 2.2 is the UDP size limitation in DNS protocol. It is caused by the IPv4 MTU setting in the early days of Internet, but it is recognized hard to change even with IPv6 and EDNS0 as well as sophisticated devices with large buffer and high performance. Different from designer of early Internet, current designer of core network and services like IP and DNS is restricted to the diversity and unpredictable behavior on the edge, due to which many problems arise such as security and scalability problem. That's one reason the memo describe the proposals in IPv6-only context when people start considering turn off their IPv4. New protocol may coined and new devices will be introduced as well as new parameter of UDP minimum size. It will be direct and effective compared with other DNS extension. The internet community like IETF/IAB/ICANN/ISOC should take this opportunity and responsibility serious in which the changes of the core protocol and key parameters should be well managed and planed influencing the evolution of Internet edge step by step, not vice versa. As to the suggestion on Enlargement of UDP minimum size parameter in IPv6-only Network. This memo give two possible value. One is 1240 octets under the MTU of IPv6 1280 octets. Another is empirical value 4096 octets following the EDNS0 practical setting (6.2.5.Payload Size Selection in RFC6891). 3.4. Introduce more IPv6-only Root Server Based on the proposal discussed in section 3.3, if the UDP Minimum Size is not confined to 512 octets, it makes possible for zones who want to expand the number their authority server beyond 13. Considering the key service of Root zone in DNS, [6] gives an algorithm that 7 more authority server can be added in the root zone in the IPv6 transport environment (with 1240 octets UDP). Considering the proposal in section 3.1 in which the DNS referral response contain only IPv6 address for each NS server, the number of IPv6-only authority server for each zone can be expanded to 27 following the same algorithm. Moreover, the number will increase remarkably if the DNS referral response size parameter is enlarged to 4096 octets which means nearly a hundred IPv6-only root servers can be introduced to make the root zone file distribution more balanced and pervasive. It's meaningful especially for emerging countries in Asia Pacific, African and Latin America areas where direct IPv6-only deployment is workable. Song & Ma Expires January 23, 2015 [Page 5] Internet-Draft IPv6-only DNS July 2014 Besides the IPv6 as a premise, to keep integrity of the zone file, in the practice, it can be a mandatory to fully support DNSSEC for the new root server application and selection process. This proposal may give the emerging countries and companies an incentive to fully support both DNSSEC and IPv6, as a reward distributing the root file locally. 4. Security Considerations ... 5. IANA Considerations ... 6. Acknowledgements Thanks to Paul Vixie forvaluable comments in forming the first version of this memo. Special thanks to the insight from discussion of ICANN ITI panel as well. 7. References [1] http://www.google.com/intl/en /ipv6/statistics.html [2] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April 2006. [3] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual- Stack Hosts", RFC 6555, April 2012. [4] P. Vixie, A. Kato and J.Abley. "DNS Response Size Issues", draft- ietf-dnsop-respsize-15(Work in Progress), February 2014. [5] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. [6] Xiaodong Lee, Paul Vixie and Zhiwei Yan. "How to scale the DNS root system?", draft-lee-dnsop-scalingroot-00(Work in Progress), July 3, 2014 Authors' Addresses Song & Ma Expires January 23, 2015 [Page 6] Internet-Draft IPv6-only DNS July 2014 Davey Song BII 2508 Room, 25th Floor, Tower A, Time Fortune Beijing 100028 P. R. China Email: songlinjian@gmail.com Di Ma ZDNS No.4, South 4th Street, Zhongguancun Beijing, Haidian 100190 P. R. China Email: madi@zdns.cn Song & Ma Expires January 23, 2015 [Page 7]