D3.3: Enable China DNS and Root-Server with IPv6

Transcription

1 Project Acronym: Project Full Title: ECIAO EU-CHINA future Internet common Activities and Opportunities Grant Agreement: Project Duration: 24 months (August July 2015) D3.3: Enable China DNS and Root-Server with IPv6 Deliverable Status: Final File Name: ECIAO_D3.3-final Due Date: 30 th September, 2014 (M14) Submission Date: 4 th December, 2014 Dissemination Level: Public Author: Latif Ladid (UL), Linjian Song, BII (BII) Copyright Copyright The EU-China FIRE Consortium Consisting of: MARTEL Martel GMBH Switzerland EGM Easy Global Market SAS France SIGMA Sigma Orionis SA France UL Université du Luxembourg Luxembourg CATR China Academy of Telecommunication Research of Ministry of Information Industry China RUIJIE Fujian Ruijie Networks CO LTD China BII BII Group Holdings LTD China

2 Disclaimer All intellectual property rights are owned by the EU-China FIRE consortium members and are protected by the applicable laws. Except where otherwise specified, all document contents are: EU-China FIRE project - All rights reserved. Reproduction is not authorised without prior written agreement. All EU-China FIRE consortium members have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the owner of that information. All EU-China FIRE consortium members are also committed to publish accurate and up to date information and take the greatest care to do so. However, the EU-China FIRE consortium members cannot accept liability for any inaccuracies or omissions nor do they accept liability for any direct, indirect, special, consequential or other losses or damages of any kind arising out of the use of this information. Deliverable Abstract This deliverable addresses the facilitation of the IPv6 infrastructure in Europe and China in cooperation with Internet Systems Consortium (ISC) and the Regional Internet Registries (RIRs) which includes the IPv6 support for the DNS system and Internet Exchanges (IXs) as well as a monitoring website. 2

3 Table of Contents 1 INTRODUCTION BACKGROUND ACTIVITIES AND PROGRESS ENABLING CHINA DNS AND ROOT-SERVER WITH IPV MONITORING IPV6 WEBSITES AND ISPS MONITORING IPV6 ISPS IPV6 DNS AND ROOT-SERVER WITH IPV6: NEXT STEPS CONCLUSION Table of Figures Figure 1: Role played by ICANN with IANA Functions... 5 Figure 2: Only 3 Root Server mirrors existed in in China in July Figure 3: BII Lab and Testbed (Paul Vixie is in the centre)... 7 Figure 4: L Root Servers were installed in July Figure 5: An example of the hierarchy of the root zone Figure 6: 13 Different Root Servers Figure 7: 4 Root Server Images in China Figure 8: New DNS Root Server Architecture with IPv6-only Root Zone Figure 9: First 30 Chinese IPv6 Websites among the Figure 10: First 4 Chinese ISP who tested IPv6 on their networks

4 1 Introduction This deliverable addresses the facilitation of the IPv6 infrastructure in Europe and China in cooperation with the Internet Systems Consortium (ISC) and the Regional Internet Registries (RIRs) which includes the IPv6 support for DNS system and Internet Exchanges (IXs) as well as a monitoring website. This Task includes the following actions: EU and China DNS and Root-Server enabled with IPv6. As the Domain Name System (DNS) is the most important infrastructure for the Internet, IPv6 will bring a new element not only to network devices but also to the Name System, especially in the Root Server. In the IPv6 environment, the administration of the Root Server will be changed accordingly, therefore, necessary work should be done in this task. In China, there is only one IX (CERNET2-IX) which is IPv6 enabled and is connected to Interenet2, WIDE and the EU but serves only educational and research purposes. Other commercial IXs are internal to the fixed and mobile operators for the time being. The task is to provide IPv6 support for more IXs in China in the wave of IPv6 commercial pilots. Create a monitoring website showing which critical organizations (Governments, ISPs, Education and selected Enterprises) in Europe and China have enabled IPv6, similar to the IPv6 Survey - Mrp.net Website: BII and UL have taken this issue previously to the highest level at ICANN by inviting the CEO of ICANN, Fadi Chehade to the IPv6 Summit on April 17 th 2013 and then organised the first ICANN conference in China on April 7 th - 11 th, 2013, both conferences taking place in Beijing. BII has been appointed by ICANN in the meantime as its point of contact for China. BII and UL have contacted Dr. Paul Vixie, Founder of the Internet Software Consortium and Designer of the software BIND which is the software that runs DNS: in order to support BII in defining the DNS and Root server strategy for China. 1.1 Background The DNS system is the key infrastructure connecting the IP Layer and Domain Layer. The Domain Name Server (DNS) translates the host names readable for humans into IP addresses communicable between internet hosts. The Root Name Server is in the root zone (Apex of DNS system) of the DNS of the Internet. A Root Server directly answers requests for records in the root zone and answers other requests by returning a list of the authoritative name servers for the appropriate top-level domain (TLD). The DNS and Root System are centralized and are mainly run and controlled by ICANN as seen in Figure 1 unlike the Internet which consist of networks and Autonomous Systems. 4

5 Figure 1: Role played by ICANN with IANA Functions There are 13 Root Servers operating with their names marked by the letters ranging from A to M. Nine of the Root Servers are located in the United States, and two are in Stockholm (I) and Amsterdam (K) and one in Tokyo (M). There are only 4 Root Server instances on the Chinese mainland; all located in Beijing, (I, F, L, and J) with fewer servers than in Bangladesh. However, there are more than 600 million internet users in China, which means that each of the four instances is responsible for 150 million internet users. The user-instance ratio is much higher than those in North America, Europe and the world average. There are 3 Root Server instances in Taiwan province and 6 in Hong Kong SAR. China is still lagging behind its neighbours, such as South Korea (5) and Japan (11). China still needs more instances or new Root Name Server Operators (RNSO) which can serve the need of an incessantly increasing community of internet users. In July 2010, there were only 3 Root Server mirrors from ISC in China as shown in Figure 2. In addition, there were no native Root Servers or ICANN L-Root Servers and none was IPv6 enabled. Obviously, this was a very inacceptable infrastructure situation which was highly condemned by the head of Research at China Academy of Telecommunication Research (CATR) at that time and they requested immediate action. 5

6 Figure 2: Only 3 Root Server mirrors existed in in China in July 2010 In order to alleviate this situation and enhance the development of the Internet infrastructure including IPv6 transition, Root Servers and IXs, the Beijing Internet Institute (BII) established a Lab called FIIT focusing on operation, testing and research in this very field. In addition, BII fully engaged in activities of the Internet community to contribute and practice the meaning of One Internet, One World. The goal of this document is to record these activities and to share some experiences. 6

7 2 Activities and progress On April 17 th, 2013, during the IPv6 summit, BII invited the CEO of ICANN, Fadi Chehade to give a keynote speech. He introduced the ICANN plan to enhance the IPv6 transition and DNS system from the ICANN perspective. On behalf of the IPv6 Forum, Mr. Latif Ladid and Mr. Liu Dong introduced the achievement of the IPv6 Forum and the intention of cooperation with ICANN. During the meeting, Fadi promised to appoint a responsible party to define the Root Server project. On September 30 th, 2013, BII co-hosted APNIC in Xi An and Mr. Liu Dong gave a welcome speech during the ceremony. During APNIC, a fruitful discussion occurred between BII and ICANN representatives on cooperation with the IPv6 transition and development of DNS system. On March 25 th, 2014, Dr. Linjian Song gave a presentation on IPv6 Transition and DNS at the ICANN Singapore meeting: Dr. Linjian Song attended the ICANN meeting in London in July and took part in the discussion with experts about IPv6-only DNS to promote the experiment suggestion on IPv6- only DNS to be written down in the ICANN ITI report: In May 2014, BII established a Lab and started to build a testbed focusing on IPv6 and Operational Testing on DNS root system as shown in Figure 3. On August 29 th, 2014, 5 top experts in this field visited BII lab and testbed. Dr. Linjian Song gave an introduction of BII and the work taking place in the lab. Some demos were shown and constructive suggestions were given by the experts. Figure 3: BII Lab and Testbed (Paul Vixie is in the centre) 7

8 In July 2014, 2 L Root Servers from ICANN were installed as shown in Figure 4. Figure 4: L Root Servers were installed in July Enabling China DNS and Root-Server with IPv6 On 27 th October, 2014, a new draft was posted to the IETF by Dr. Linjian Song and Dr. Paul Vixie (Founder of the Internet Software Consortium and Designer of the software BIND which is the software that runs DNS) about consideration on IPv6-only DNS deployment. ( Following are the essential parts of the Internet Draft, supplemented with explanations. 8

9 Sunset4 Working Group Internet-Draft Intended status: Informational Expires: April 30, 2015 L. Song Beijing Internet Institute P. Vixie Farsight Security, Inc. D. Ma ZDNS October 27, 2014 Considerations on IPv6-only DNS Development draft-song-sunset4-ipv6only-dns-00 Abstract Deployment of IPv6-only networks is impacted by assumptions of IPv4-only or dual-stack transition scenarios. For example, these assumptions are in the operations of DNS. This document intends to revisit the behavior and implicit inertial in the current system and hopes to propose a mitigation technique. Introduction It's commonly believed that the dual-stack model is the best practice for IPv6 transition in which IPv4 and IPv6 function can work in parallel without mutual interference. Based on this model, IP stacks and applications are expected to be converted into IPv6 smoothly when the IPv4 address pool run out. The dual-stack approach gives IPv4/IPv6 capability on end system, network devices, DNS and application servers, but, as a side effect, brings additional problems, such as IPv4 fallback [RFC6555] or even IPv4/IPv6 competition. This issue makes the dual stack model more complicated to deploy and manage and makes the overall network less reliable. To accelerate the transition to a fully connected IPv6 network, IPv6-only experiments [RFC6586] and IETF standards [RFC6333], [RFC7040] are documented. Some techniques verify IPv6 capability and support the IPv6- only deployment. In IPv6-only environments, DNS resolvers or modules are provisioned only with IPv6 address. It is mainly due to three aspects: 1) To save freer IPv4 addresses in deploying new DNS resolvers (or proxies). 2) To reduce the management cost and risk in dual stack environment. 3) To follow the inherent requirement in some IPv6 Transition technologies, such as DS-Lite [rfc6333]. It's worthwhile to mention that the tunnel technology provides an approach that allows IPv6-only network deployment become independent from the rest of the world which makes the IPv6-only strategy much popular. In the IPv6- only network, the ISPs only provision IPv6 address to the end system, network and DNS element via DHCPv6. However, IPv6-only resolver will face an Internet which are partly running in IPv4 only environment and partly in dual-stack, yet with IPv4-prefered paradigm. As a result, the DNS element in IPv6-only environment is suggested to be forwarding requests by relying on the upstream dual-stack DNS recursive server section 5.5 in [RFC6333]. However, using the DNS proxy mechanism is a compromise in IPv6 transition context, which still has implicit limitations [RFC5625]. 9

10 This memo revisits the behavior and implicit inertia of DNS in existing architecture which may hinder the IPv6-only DNS deployment. Complementary information from ECIAO: DNS server and Root Server: A Domain Name Server translates the host names so that it is readable for humans into IP addresses communicable between internet hosts. The Root Name Server is in the root zone of the Domain Name System (DNS) of the Internet. DNS converts internet domain names and the Root Server directly answers requests for records in the root zone and answers other requests by returning a list of the authoritative name servers for the appropriate top-level domain (TLD). The authoritative name servers that the resolvers use to find top level domains are the root name servers. Figure 5: An example of the hierarchy of the root zone Terminology A: A resource record type used to specify an IPv4 address [RFC1034] AAAA: A resource record type used to specify an IPv6 address [RFC3596] EDNS0: Version 0 of Extension mechanisms for DNS [RFC6891] DNSSEC: DNS Security Extensions [RFC4033] MTU: Maximum Transmission Unit, the maximum size for a datagram to be forwarded on an interface without needing fragmentation [RFC0791], [RFC2460] Additional Section: Section in DNS query/response carrying RRs which may be helpful in using the RRs in the other sections [RFC1034]. Note that in this document the data in additional section is the A/AAAA information of NS server, particular for root zone. Complementary information from ECIAO: Problem Statement: Uneven distribution of Root system As previously mentioned in the previous Section, there are 13 Root Servers operating with the letters ranging from A to M. 10

11 Figure 6: 13 Different Root Servers The map above in Figure 6 shows the geographic locations of the 13 different Root Servers. The chart [Root-Uneven-distribution] done in 2012 shows the internet-connected population that each Root Server instance bears. It can be seen that there are 20,335,982 people for each Root Server instance in Asia, 8,742,203 in Africa, 8,557,888 in the Middle East, 8,426,945, in South America, 4, 957,660 in Europe, 3,750,804 in North America, 1,407,497 in Oceania, and the world average is 7,557,446. The status quo in Greater China for example is 4 Root Server images as shown in Figure 7. Figure 7: 4 Root Server Images in China DNS Referral Response Size limitation Due to the required minimum IP reassembly limit for IPv4, the original DNS standard [RFC1034], [RFC1035] limited the UDP message size to 512 octets. It became an historical and practical hard DNS protocol limit, even after EDNS0 [RFC6891] was introduced to mitigate this issue [draft-ietf-dnsoprespsize-15]. This limit presents problems for zones wishing to (1) add more authority servers or (2) advertise the IPv6 addresses of newly updated dual-stack NS name servers or (3) use DNSSEC. In the context of this document, the limitation may be relaxed due to the larger base MTU of IPv6 (1280 octets) which is the default for IPv6-only networks. Additional section in IPv4/IPv6 Environments Given there is hard limitation in the DNS referral response size, the 11

12 implementations preferably decides to keep as much data as possible in the UDP responses no matter whether it is "critical" or "courtesy" (Refer to Appendix B.2 in [RFC4472]). It is a typical case in priming exchange between recursive resolver and the Root Server. When a name server resolver bootstraps, it performs the NS lookup for the root zone. In the response packet from Root Server, the additional section is supposed to contain all the A & AAAA records of NS domain name. Ultimately, when all 13 root name servers are assigned IPv6 addresses, the priming response will increase in size to 800 bytes. There are different strategies for Root Server operators to choose which RRset (A or AAAA) should be in the additional data if not all of the glue information can be included. Note that in dual-stack environment, IPv4 glue and IPv6 glue of the same zone are actually competing for the room of DNS UDP packets. For example, some of the DNS Root Servers prefer to return as many IPv4 glue records as possible. In that case only 2 out 10 IPv6 glues are included as shown below, irrespective of IPv4 or IPv6 DNS transport. ;; ADDITIONAL SECTION: a.root-servers.net IN A b.root-servers.net IN A c.root-servers.net IN A d.root-servers.net IN A e.root-servers.net IN A f.root-servers.net IN A g.root-servers.net IN A h.root-servers.net IN A i.root-servers.net IN A j.root-servers.net IN A k.root-servers.net IN A l.root-servers.net IN A m.root-servers.net IN A a.root-servers.net IN AAAA 2001:503:ba3e::2:30 b.root-servers.net IN AAAA 2001:500:84::b In the context of IPv6-only deployments, these glue records are much less optimal. They are based on IPv4 or dual-stack assumptions, where IPv4 is still dominant. It may negatively impact the IPv6 service in IPv6-only deployments. If the glue set sent in the response is correlated with the IP version of the DNS transport, then the answer, in most cases, will be more optimal. However, there are two reasons why it is not adopted as an optimization. One is that it breaks the DNS transport model of independence and resource records in Section 1.2 in [RFC4472]. Another reason is that it will bring unpredictable risk to the performance and stability of the current Root Server system. DNS proxy In IPv6-only networking, DNS proxy approach is recommended for IPv6-only 12

13 DNS element since it avoids the difficulty to perform all DNS resolution over IPv6 transport, given that still many networks on the Internet are only on IPv4. On the other hand, it loses the opportunity to perform a full recursive resolver function via IPv6, at least in Root and TLD level which are mostly IPv6 enabled. In additional, as described in the beginning of [RFC5625], the DNS proxy function is not an optimal solution to serve the IPv6-only resolver requirement. Large packets caused by priming request or DNSSEC validation packets will be blocked due to the proxy implementation. It is suggested that: "To ensure full DNS protocol interoperability it is preferred that client stub resolvers should communicate directly with fullfeature, upstream recursive resolvers wherever possible." As more and more NS servers are updated to IPv6 transport and reachable over the IPv6 Internet, the direct IPv6 resolution will be preferable in IPv6-only resolver. But regarding the long-tailed feature of IPv6 adoption in NS servers, certain back-forward compatible mechanism should be designed, which indeed makes an incentive model for IPv6 adoption over IPv4 as well. Complementary information from ECIAO: Considerations on mitigation approach To support IPv6-only public testing and deployment on a wide scale and avoid destabilizing the current Root Server system, this document proposes to establish a second trial infrastructure which is basically composed of three parts: new IANA operations, IPv6-only Root Servers and DNS resolvers. IANA function and operation Figure 8: New DNS Root Server Architecture with IPv6-only Root Zone In the current practice of Root zone management, IANA first receives the TLD updates from TLD operators. After vetting and going through the authorizing process to confirm the changes to the Root zone, the zone maintainer (currently Verisign) will be notified to edit and sign the zone file, then distribute it to the 12 Root Server operators. In the current architecture, one intuitive approach is to ask IANA to add at least two additional letters "N" and "O" into the current 13 letters with dedicated IPv6-only NS servers. There are however, two reasons why this is not preferable. First, following the DNS response mechanism from current Root Servers, the possibility that the newly added IPv6 glue information will 13

14 not be advertised via additional data exists. The second is that this approach will bring impact and risk to the current Root Server system causing a break in our principle. We therefore suggested to IANA to produce an additional form of the DNS root zone (variant root zone) as depicted in Figure 8. The new DNS root zone means there should be additional forms of hint file and new root zone file with different Apex NS record set. Note that the additional ZSK/KSK in DNSSEC process is optional for IANA. The following examples shows the Apex NS record set for IPv6-only variant root zone including address glue. This data would be included in a variant root zone before DNSSEC signing, and can also be published as a "root hint" file. IN NS X1.iana-servers.net. IN NS X2.iana-servers.net. $ORIGIN iana-servers.net. X1 IN AAAA 2001:?:3::1 X2 IN AAAA 2001:?:4::2 In this case, although there exist two root zones, they are all vetted and signed by a unique IANA function which guarantees the "One Internet" principle. IPv6-only Root Server Accordingly, our goal is that the new RNSO will adopt the new strategies and technologies to better serve the IPv6-only network. For example, the new server will return the full IPv6 glue with higher priority in the priming response. As to the operation requirement for IPv6-only Root Server, there is no particular difference from the current practice of 13 Root Servers. The only notable change is that the IPv6-only Root Servers are expected to subscribe to the IPv6-only Root zone from IANA which will transfer the zone data via AXFR/IXFR as well. The users (resolver) will follow the guide of the new hint file to find the IPv6-only Root Server as its entrance. It is out of the scope to discuss how to choose IPv6-only operators to host the new root zone. But it is worthwhile to mention how many operators can be present on the new Root Server list. Based on the fact that IPv6 MTU is 1280 octets, we can calculate that 7 additional authority servers which can be added in the root zone if the DNS referral response contains all the IPv4 and IPv6 addresses. Considering the case that DNS referral response contain only IPv6 addresses for each NS server, the number of the authority server for the root zone can be expanded to 27. IPv6-only Recursive Resolver Given that IANA provides two forms of root zone, IPv6-only resolver has the choice of different hint files. If they choose the new IPv6-only hint file and make a priming request when it bootstraps, they will get consistent IPv6 glue information. It is important especially when the IPv6 network is not fully connected as IPv4 and the more IPv6 glue is received on the resolver side and in this regard, means much more stability. 14

15 As to the behavior of IPv6-only resolver, it receives all the IPv6 glue information from Root level via IPv6-only root. But when it comes to TLD and second level domain which has no AAAA record for its NS server, IPv6-only resolver should make a patch to fall back to Proxy function in order to continue the services. It can run the two modes simultaneous making the proxy as a backup or using the happy eyeballs [RFC6555] approach. Relations with Existing 13 root It is encouraging that the current 12 root operators can allocate new servers to host the IPv6-only root zone in parallel with existing IPv6 dual stack servers. References [Root-Uneven-distribution] [I-D.ietf-dnsop-respsize] Vixie, P., Kato, A., and J. Abley, "DNS Referral Response Size Issues", draft-ietf-dnsop-respsize-15 (work in progress), February [I-D.lee-dnsop-scalingroot] Lee, X., Vixie, P., and Z. Yan, "How to scale the DNS root system?", draft-lee-dnsop-scalingroot-00 (work in progress), July [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, April [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual- Stack Hosts", RFC 6555, April [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April [RFC7040] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public IPv4- over-ipv6 Access Network", RFC 7040, November

16 3 Monitoring IPv6 Websites and ISPs 3.1 Monitoring IPv6 Websites An IPv6-enabled Website program ( has been introduced to test IPv6 Websites for their IPv6 enablement. In the following list in Figure 9, some 600 Chinese Websites have applied and passed the IPv6 WWW logo test and activated IPv6 on their Website. This logo is published on their Website. 16

17 Figure 9: First 30 Chinese IPv6 Websites among the Monitoring IPv6 ISPs A similar IPv6-enabled ISP program ( as shown in Figure 10 has been introduced to test ISP for the Chinese IPv6 enablement. In the following list, some 4 Chinese ISPs have applied and passed the IPv6 ISP logo test and activated IPv6 on their network. This logo is published on their Website. 17

18 Figure 10: First 4 Chinese ISP who tested IPv6 on their networks 3.3 IPv6 DNS and Root-Server with IPv6: Next Steps The next steps to further advance IPv6 DNS and Root-Server with IPv6 are defined in the following Action Table with confirmed activities, responsible partner and targeted milestone dates. Action Partner involved Milestone Define an IPv6 DNS & Root-Server plan for China BII, UL M13 (September 2014) Meetings with ICANN Chair and RS experts in BII, UL M14 (October 2014) M15 (November 2014) ICANN Events were held in Beijing to follow-up BII M20 (April 2015) Get Stakeholders to deploy L-RS in China BII M21-M24 Get Stakeholders to deploy IPv6 DNS in China BII M21-M24 18

19 4 Conclusion An unexpected and amazing contribution has been achieved by BII especially since Paul Vixie is redefining the use of Root Servers to use IPv6-only in his recent discussions: We propose that IANA produce several additional forms of the DNS root zone, to allow universal anycast and operational research. Operational research in this context includes wide scale public testing of IPv6-only root name service and wide scale public testing of new gtld collision effects. A second variation on the current root zone would provide universal anycast as above, but would denote name servers that had only IPv6 connectivity (indicated by the presence of AAAA records) and no IPv4 connectivity (as indicated by the absence of A records). This variation would facilitate operational research into IPv6-only networking. The aforementioned RFC is a major contribution to the Internet at large and will advance the Internet infrastructure in the right direction. BII can only be immensely congratulated for this effort which will have a far reaching impact not only for this project and the relationship between EU and China but for the future of the Internet at large. 19