Internet DRAFT - draft-davey-sunset4-ipv6onlydns

draft-davey-sunset4-ipv6onlydns







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]