Internet DRAFT - draft-song-sunset4-ipv6only-dns

draft-song-sunset4-ipv6only-dns







Sunset4 Working Group                                            L. Song
Internet-Draft                                Beijing Internet Institute
Intended status: Informational                                  P. Vixie
Expires: April 30, 2015                          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 are impacted by assumptions of
   IPv4-only or dual-stack transition scenarios.  For example, these
   assumptions are in the operations of DNS.  This memo is problem
   statement and hopes to eventually propose a mitigation technique.

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 30, 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
   include Simplified BSD License text as described in Section 4.e of



Song, et al.             Expires April 30, 2015                 [Page 1]

Internet-Draft          IPv6-only DNS Development           October 2014


   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  . . . . . . . . . . . . . . . .   3
     3.1.  DNS Referral Response Size limitation . . . . . . . . . .   3
     3.2.  Additional section in IPv4/IPv6 Environments  . . . . . .   4
     3.3.  DNS proxy . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Mitigation approach . . . . . . . . . . . . . . . . . . . . .   6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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, IP stacks
   and applications are expected to be converted into IPv6 smoothly when
   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
   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 more free IPv4 addresses in deploying new DNS resolvers;

   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];




Song, et al.             Expires April 30, 2015                 [Page 2]

Internet-Draft          IPv6-only DNS Development           October 2014


   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 be forwarding requests by relying on the
   upstream dual-stack DNS recursive server section 5.5 [1] in
   [RFC6333].  However, using the 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 my hinder the IPv6-only DNS development.

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.

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][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-dnsop-respsize-15].  This limit presents s for
   zones wishing to (1) add more authority servers or (2) advertise the




Song, et al.             Expires April 30, 2015                 [Page 3]

Internet-Draft          IPv6-only DNS Development           October 2014


   IPv6 addresses of newly updated dual-stack NS name servers, or (3)
   use DNSSEC.

   In the context of this memo, the limitation may be relaxed due to the
   larger base MTU of IPv6 (1280 octets) which is the default for
   IPv6-only networks.

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, some of 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.  518400 IN A 198.41.0.4

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

   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



Song, et al.             Expires April 30, 2015                 [Page 4]

Internet-Draft          IPv6-only DNS Development           October 2014


   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 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
   services 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.  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 avoids the difficulty to
   perform all DNS resolution over IPv6 transport, given that still many
   networks on Internet are only on IPv4.  On another 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 full-feature, upstream recursive resolvers
   wherever possible."

   As more and more NS servers 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-tail feature of IPv6
   adoption in NS servers, certain back-forward compatible mechanism




Song, et al.             Expires April 30, 2015                 [Page 5]

Internet-Draft          IPv6-only DNS Development           October 2014


   should be designed, which indeed make an incentive model for IPv6
   adoption over IPv4 as well.

4.  Mitigation approach

   TBD

5.  Security Considerations

   TBD

6.  IANA Considerations

   TBD

7.  Acknowledgements

   TBD

8.  References

8.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.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, 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.



Song, et al.             Expires April 30, 2015                 [Page 6]

Internet-Draft          IPv6-only DNS Development           October 2014


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

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

8.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
   Beijing Internet Institute
   2508 Room, 25th Floor, Tower A, Time Fortune
   Beijing  100028
   P. R. China

   Email: songlinjian@gmail.com









Song, et al.             Expires April 30, 2015                 [Page 7]

Internet-Draft          IPv6-only DNS Development           October 2014


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

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


   Di Ma
   ZDNS
   Beijing
   P. R. China

   Email: madi@zdns.cn



































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