[dns-operations] Comments welcome : draft-song-dnsop-ipv6only-dns-00

Davey Song songlinjian at gmail.com
Fri Oct 10 21:11:06 UTC 2014


Hi everyone,

I have recently proposed a draft on the IPv6-only DNS deployment. Here is
the abstract of this draft:

Abstract

   Focused on the IPv6 transition scenarios with IPv6-only networks,
   this memo revisits the behavior and implicit inertia of DNS which may
   hinder the IPv6-only DNS deployment.  To ease the situation, this
   memo intend to introduce a second infrastructure to support IPv6-only
   DNS experiment and development, especially in the newly developed
   IPv6 only network.

It is still an early version of a simple idea. I'm writing this letter to
collect the comments and feedback from the community, pro or con, which
will help us to better understand this issue and better preparation for a
IETF draft.

Anyone who will contribute this discussion, thank you in advance.

Best regards,
Davey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141011/3ba327b3/attachment.html>
-------------- next part --------------




DNSOP Working Group                                              L. Song
Internet-Draft                                                       BII
Intended status: Standards Track                                P. Vixie
Expires: April 13, 2015                          Farsight Security, Inc.
                                                                    D. Ma
                                                                    ZDNS
                                                        October 10, 2014


                    Considerations on IPv6-only DNS
                    draft-song-dnsop-IPv6only-DNS-00

Abstract

   Focused on the IPv6 transition scenarios with IPv6-only networks,
   this memo revisits the behavior and implicit inertia of DNS which may
   hinder the IPv6-only DNS deployment.  To ease the situation, this
   memo intend to introduce a second infrastructure to support IPv6-only
   DNS experiment and development, especially in the newly developed
   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 April 13, 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



Song, et al.             Expires April 13, 2015                 [Page 1]


Internet-Draft                IPv6-only DNS                 October 2014


   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Revisit to current situation  . . . . . . . . . . . . . . . .   4
     3.1.  DNS Referral Response Size limitation . . . . . . . . . .   4
     3.2.  Additional section in IPv4/IPv6 Environments  . . . . . .   4
     3.3.  DNS proxy . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  An additional DNS architecture  . . . . . . . . . . . . . . .   6
     4.1.  IANA function and operation . . . . . . . . . . . . . . .   6
     4.2.  IPv6-only Root server . . . . . . . . . . . . . . . . . .   8
     4.3.  IPv6-only Recursive Resolver  . . . . . . . . . . . . . .   9
     4.4.  Relations with Existing 13 root . . . . . . . . . . . . .   9
   5.  Risk and Impact Considerations  . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  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, most
   things are expected to be converted into IPv6 smoothly when IPv4
   address pool run out.  However dual-stack approach not only gives
   IPv4/IPv6 capability on end system, network devices, DNS and
   application servers, but also brings some problems (IPv4
   fallback)[RFC6555] or even IPv4/IPv6 competition as a side effect
   which makes the dual stack model complicated.

   To accelerate the transition to a fully connected IPv6 network, there
   are some works on IPv6-only experiments [RFC6586] and IETF standards
   [RFC6333], [RFC7040] which verify IPv6 capability and support the
   IPv6-only deployment.  Particularly on domain name system in ISP
   network, it's expected that more and more DNS resolvers or modules
   will be provisioned with only IPv6 address.  It is mainly due to
   three aspects:

   1) To save more free IPv4 addresses in deploying new DNS resolvers;



Song, et al.             Expires April 13, 2015                 [Page 2]


Internet-Draft                IPv6-only DNS                 October 2014


   2) To reduce the cost and risk of management in dual stack
   environment;

   3) To follow the inherent requirement in the IPv6 transition
   scenarios, such as DS-Lite [RFC6333];

   It's worthwhile to mention that the tunnel technology provides an
   approach that allow IPv6-only network deployment become independent
   from the rest of the world which makes the IPv6-only strategy much
   porpular.  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 adopt proxy function and rely on the
   upstream dual-stack DNS recursive server section 5.5 [1] in
   [RFC6333].  However, using DNS proxy mechanism is a compromise in
   IPv6 transition context, which still has implicit limitations
   [RFC5625].

   This memo revisits the behavior and implicit inertia of DNS in
   existing architecture which may hinder the IPv6-only DNS deployment.
   Given there are an increasing number of DNS resolvers who only speak
   IPv6, this memo intends to introduce an additional DNS infrastructure
   to break through the inertia such as the usage of DNS proxy and
   response paradigm, which can support IPv6-only DNS experiment and
   development, especially in the newly developed IPv6 only network.

2.  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 memo the data in additional section is the A/AAAA
   information of NS server, particular for root zone.




Song, et al.             Expires April 13, 2015                 [Page 3]


Internet-Draft                IPv6-only DNS                 October 2014


3.  Revisit to current situation

3.1.  DNS Referral Response Size limitation

   Due to the required minimum IP reassembly limit for IPv4, the
   original DNS standard [RFC1034/1035] limited the UDP message size to
   512 octets.  It became a historical and practical hard DNS protocol
   limit, no matter EDNS0 [RFC6891] was 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, or (3) use DNSSEC.

   In the context of this memo, the limitation is relaxed a little bit
   due to the larger MTU of IPv6 (1280 octets) which will be taken as a
   premise when we consider the new infrastructure.

3.2.  Additional section in IPv4/IPv6 Environments

   Given there is hard limitation in the DNS referral response size, the
   implementations preferably decide to keep as much data as possible in
   the UDP responses no matter it is "critical" or "courtesy"
   Appendix B.2 in [RFC4472] .  It is a typical case in priming exchange
   between recursive resolver and root server.  When a name server
   resolver bootstrap, it performs the NS lookup for 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 same zone are actually
   competing for the room of DNS UDP packets.  For example, in the
   implementation of L root server which is run by ICANN, prefers to
   return more IPv4 glues as much as possible.  In that case only 2 out
   10 IPv6 glues are included.

   If we execute dig . ns @l.root-servers.net , we can simply found the
   content in additional section as follows, no matter via IPv4 or IPv6
   DNS transport.

   ;; ADDITIONAL SECTION:

   a.root-servers.net.  518400 IN A 198.41.0.4

   b.root-servers.net.  518400 IN A 192.228.79.201




Song, et al.             Expires April 13, 2015                 [Page 4]


Internet-Draft                IPv6-only DNS                 October 2014


   c.root-servers.net.  518400 IN A 192.33.4.12

   d.root-servers.net.  518400 IN A 199.7.91.13

   e.root-servers.net.  518400 IN A 192.203.230.10

   f.root-servers.net.  518400 IN A 192.5.5.241

   g.root-servers.net.  518400 IN A 192.112.36.4

   h.root-servers.net.  518400 IN A 128.63.2.53

   i.root-servers.net.  518400 IN A 192.36.148.17

   j.root-servers.net.  518400 IN A 192.58.128.30

   k.root-servers.net.  518400 IN A 193.0.14.129

   l.root-servers.net.  518400 IN A 199.7.83.42

   m.root-servers.net.  518400 IN A 202.12.27.33

   a.root-servers.net.  518400 IN AAAA 2001:503:ba3e::2:30

   b.root-servers.net.  518400 IN AAAA 2001:500:84::b

   In the context of this memo, it is much less being right to follow
   the existing response paradigm, when we consider the IPv6-only
   resolver deployment.  It's will be unrecoverable and become a
   disaster, if (1)major part of IPv6 NS servers for Root zone are
   absent and (2)the resolver did not issue one or more additional
   queries for performance consideration.

   It is also proposed that it will be wiser to take the transport of
   DNS query as a hint to decide which additional data should be set.
   There are two reasons why it is not adopted as an optimization.  One
   is that it breaks the model of independence of DNS transport and
   resource records section 1.2 [2] in [RFC4472].  Another is that it
   will bring unpredictable risk to the performance and stability of
   current root server system.

3.3.  DNS proxy

   In IPv6-only networking, DNS proxy approach is recommended for
   IPv6-only DNS element.  On one hand, it benefits by avoiding the
   difficulty to perform all DNS resolution over IPv6, given the fact
   that NS server are still IPv4 only for large website which already
   provide IPv6 services for their users, such as google, Yahoo and



Song, et al.             Expires April 13, 2015                 [Page 5]


Internet-Draft                IPv6-only DNS                 October 2014


   Wikipedia.  On another hand, it lose the opportunity to perform a
   full recursive resolver function via IPv6, at least in Root and TLD
   level which is mainly 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 cause 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 full-feature, upstream recursive resolvers
   wherever possible."

   As more and more NS servers updated to IPv6-enabled, the direct IPv6
   resolution will be preferable in IPv6-only resolver.  But regarding
   the long-tail feature of IPv6 adoption in NS servers, certain back-
   forward compatible mechanism should be designed, which indeed make an
   incentive model for IPv6 adoption over IPv4 as well.

4.  An additional DNS architecture

   To support IPv6-only public testing and deployment in a wide scale
   and avoid destabilizing the current root server system in the same
   while, this memo proposes to setup a second infrastructure which is
   basically composed of three parts : new IANA operations, IPv6-only
   root servers and DNS resolvers.

4.1.  IANA function and operation























Song, et al.             Expires April 13, 2015                 [Page 6]


Internet-Draft                IPv6-only DNS                 October 2014


                   +------------+
                   |TLD operator|
                   +-----+------+
                         | TLD update
            +------------v------------+
            |                         |
            |Vetting and Authorizing  |
            |                         |
            +-----------+-------------+
                        |
         +--------------v----------------+
         |                               |
         |         Editing and Signing   |
         |                               |
         +----+--------------------+-----+
              |                    |
      +-------v-------+   +--------v--------+
      |               |   |                 |
      | Existing Root |   | IPv6-only Root  |
      | Zone Data     |   | Zone Data       |
      |               |   |                 |
      +-------+-------+   +--------+--------+
              |                    |
   +----------v------+    +--------v--------+
   |                 |    |                 |
   | Root servers:   |    | IPv6-only Root: |
   | A,B,C,D,...,M   |    | X1,X2,X3...     |
   |                 |    |                 |
   +-----------------+    +-----------------+

   Figure 1 New DNS Root 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 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 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 ones with
   dedicated IPv6-only NS servers.

   There are two reasons why it is not preferable.  First, following the
   DNS response mechanism from current Root servers, it is large
   possibility that the newly added IPv6 glue information will not be
   advertised via additional data.  The second is that this approach
   will bring the impact and risk to the current root server system
   which is breaking our principle.




Song, et al.             Expires April 13, 2015                 [Page 7]


Internet-Draft                IPv6-only DNS                 October 2014


   In this memo we suggest IANA to produce an additional form of the DNS
   root zone (variant root zone) as we depict in figure 1.  The new DNS
   root zone means there should be an 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 example show 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 would be
   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 exists two root zones, they are all
   vetted and signed by unique IANA function which guarantee the "One
   Internet" principle.

4.2.  IPv6-only Root server

   According to our goal in this memo, the new Root servers (Root
   operator) 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 current practice of 13 root servers.
   The only notable change is that the IPv6-only Root servers are
   expected to subscribe the IPv6-only Root zone from IANA which will
   transfer the Zone data via AXFR/IXFR as well.  The users (resolver)
   will following the guide of new hint file to find the IPv6-only Root
   server as its entrance.

   Although it is out of scope in this memo 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 in the new root server
   list.  Based on that IPv6 MTU is 1280 octets, we can calculate that 7
   more authority server can be added in the root zone if the DNS
   referral response contain all the IPv4 and IPv6 address.  Considering
   the case that DNS referral response contain only IPv6 address for




Song, et al.             Expires April 13, 2015                 [Page 8]


Internet-Draft                IPv6-only DNS                 October 2014


   each NS server, the number of authority server for the root zone can
   be expanded to 27.

4.3.  IPv6-only Recursive Resolver

   Given that IANA provides two forms of root zone, IPv6-only resolver
   has the choice to different hint files.  If they choose the new
   IPv6-only hint file and make a priming request when it bootstrap,
   they will get consistent information of IPv6 glue.  It is important
   especially when IPv6 network is not fully connected as IPv4.  More
   IPv6 glue received in resolver side means much more stable in this
   regard.

   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 to continue the services.  It can run the two modes
   simultaneous making the proxy as a backup or using happy
   eyeballs[RFC6555] approach.

4.4.  Relations with Existing 13 root

   It is encouraging that current 12 root operators can allocate new
   servers to host the IPv6-only root zone in parallel with existing
   IPv6 dual stack servers.

5.  Risk and Impact Considerations

   TBD

   1) IANA root zone management doubled.  Single DNSSEC key or two keys?

   2) Introduce new server/operator will cause risk to unstable
   situation

   3) Make recursive resolver complicated.  Pro and Con analysis are
   necessary.  Is it worth for IPv6-only resolver to do so?

6.  Security Considerations

   TBD

7.  IANA Considerations

   IANA should produce an additional form of the DNS root zone (variant
   root zone) to allow IPv6-only public testing and deployment in a wide
   scale.



Song, et al.             Expires April 13, 2015                 [Page 9]


Internet-Draft                IPv6-only DNS                 October 2014


8.  Acknowledgements

   TBD

9.  References

9.1.  Normative References

   [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 2014.

   [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 2014.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC3596]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              October 2003.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4472]  Durand, A., Ihren, J., and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", RFC 4472, April
              2006.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines", BCP
              152, RFC 5625, August 2009.

   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", RFC 6333, August 2011.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, April 2012.



Song, et al.             Expires April 13, 2015                [Page 10]


Internet-Draft                IPv6-only DNS                 October 2014


   [RFC6586]  Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
              Network", RFC 6586, April 2012.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.

   [RFC7040]  Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
              IPv4-over-IPv6 Access Network", RFC 7040, November 2013.

9.2.  URIs

   [1] http://tools.ietf.org/html/rfc6333#section-5.5

   [2] http://tools.ietf.org/html/rfc4472#section-1.2

Authors' Addresses

   Linjian Song
   BII
   2508 Room, 25th Floor, Tower A, Time Fortune
   Beijing  100028
   P. R. China

   Email: songlinjian at gmail.com


   Paul Vixie
   Farsight Security, Inc.
   155 Bovet Road, #476
   San Mateo, CA  94402
   USA

   Phone: +1 650 489 7919
   Email: vixie at farsightsecurity.com


   Di Ma
   ZDNS
   Beijing
   P. R. China

   Email: madi at zdns.cn









Song, et al.             Expires April 13, 2015                [Page 11]


More information about the dns-operations mailing list