[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00

sunset4                                                    J. Brzozowski
Internet-Draft                                               P. Ebersman
Intended status: Best Current Practice                     Comcast Cable
Expires: May 5, 2016                                   November 02, 2015


                       DNS Forwarding and IPv4aaS
              draft-jjmb-sunset4-dns-forwarding-ipv4aas-00

Abstract

   The depletion of IPv4 coupled with the wide spread deployment of IPv6
   for broadband globally is creating an environment where service
   providers can seriously begin to consider alternate uses and
   applications for native IPv6 connectivity.  Pervasive, reliable
   support for IPv6 across many access technologies suggests that one
   critical use for native IPv6 is the carry legacy IPv4 communications.
   Today this is referred to as IPv4 as a Service (IPv4aaS).  IPv4aaS
   can leverage a variety of transports ranging from Mapping of Address
   and Ports (MAP) to Generic Route Encapsulation (GRE) along with other
   viable protocols.  Most every use case for IPv4aaS includes the use
   of CG-NAT, however, this is not strictly required.  The purpose of
   this document is to hone in on DNS specific behavior that must be
   taken into consideration as the deployment of IPv4aaS advances
   globally.

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 May 5, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Brzozowski & Ebersman      Expires May 5, 2016                  [Page 1]


Internet-Draft                                             November 2015


   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
   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.  Topology  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Name resolution . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Current expected behavior . . . . . . . . . . . . . . . .   4
     4.2.  Impact to IPv4aaS . . . . . . . . . . . . . . . . . . . .   4
     4.3.  Recommended best practice . . . . . . . . . . . . . . . .   4
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   5
   6.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   10. Informative References  . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The exhaustion of IPv4 along with the introduction of IPv4 as a
   Service (IPv4aaS) introduces a challenge as it relates to dual stack
   customer premise environments which are likely to be wide spread for
   years to come.

   Host operating systems will continue to operate in dual stack mode
   with the expectation that off customer premise network communications
   will be predominantly IPv6 only.  The use of IPv4 ideally would be
   limited to in customer premise network communications.  The reality
   of the situation with a dual stack customer premise is that within
   local area networks there will inevitably be applications and
   services that lag in their support of IPv6.  These applications will
   unfortunately find that their network-based communications, which are
   IPv4 only, will be carried to carrier grade network address
   translation (CG-NAT) devices that are located else where in the
   service provider network.  The focus of this document is DNS
   [RFC1034] resolution in such an environment, not the overarching
   protocol flows for the multitude of applications and services.




Brzozowski & Ebersman      Expires May 5, 2016                  [Page 2]


Internet-Draft                                             November 2015


   Interaction with DNS plays a critical role in how applications behave
   and perform.  The transportation of IPv4 DNS queries over an IPv4aaS
   infrastructure may have a significant impact on the applications,
   service, customer, and ultimately the service provider
   infrastructure.

   In order for IPv4aaS to be viable a customer premise must have IPv6
   connectivity if IPv6 is to be the transport for IPv4.  The same IPv6
   transport is also used to support native IPv6 based communications to
   and from the Internet.  The IPv6 connectivity provided today can and
   should be leveraged to support improved communications for IPv4
   hosts, nodes, applications, and services that reside on the customer
   premise LAN.

2.  Terminology

   o  CG-NAT - Carrier Grade Network Address Translation for IPv4

   o  IPv4aaS - IPv4 for as a Service is generically used to refer to
      the use of IPv6 as a transport for IPv4 communications

3.  Topology

   The topology for a customer premise network where IPv4aaS is being
   used to support legacy IPv4 only communications is as follows:

   o  Dual stack customer premise LAN

   o  Single stack IPv6 only customer WAN

   o  RFC1918 addressing is utilized for IPv4

   o  Globally routable IPv6 is delegated and assigned to the customer
      premises router

   o  IPv6 configuration options including DNS server IPv6 addresses are
      assigned and configured to the customer premises router

   The technologies used to enable IPv4aaS may vary; examples of popular
   technologies include GRE over IPv6 [I-D.ietf-intarea-gre-ipv6] and
   Mapping of Address and Port MAP-E [RFC7597] / MAP-T [RFC7599].  For
   the purposes of this document Internet facing IPv4 communications are
   assumed to traverse a CG-NAT.








Brzozowski & Ebersman      Expires May 5, 2016                  [Page 3]


Internet-Draft                                             November 2015


4.  Name resolution

4.1.  Current expected behavior

   Today customer premise LANs typical leverage one or more of the
   following.  For both IPv6 and IPv4 one more of the following apply:

   o  All DNS queries are sent by default to the customer premises
      router, typically 10.0.0.1 for example.  The router may implement
      a DNS proxy or will simply forward to an alternate DNS server for
      resolution.

   o  All hosts on the customer LAN are assigned the publicly routable
      IPv4 address of DNS servers on the Internet, which may include DNS
      recursive name server supported by the service provider.

   o  Finally, hosts on the customer LAN may also utilize a DNS server
      that is administered locally.  This DNS server may resolve local
      names and addresses and will forward DNS queries it cannot satisfy
      using one or more of the approaches listed above.

4.2.  Impact to IPv4aaS

   When legacy IPv4 communications require support from the customer LAN
   and if DNS over IPv4 is used today most of the above would result in
   one of the following:

   o  Added round trip for DNS over IPv4 over the IPv4aaS infrastructure

   o  Less accurate, coarse grained geo-location information

   o  The DNS query being processed by the CG-NAT

4.3.  Recommended best practice

   Since the customer premise router is assumed to have IPv6
   connectivity and minimally a DNS server IPv6 address an optimization
   should be utilized to address the potential performance impact to DNS
   and geo-location minimally:

   o  Hosts must prefer the use of DNS over IPv6 for all query types,
      including A RR queries.  This assumes that a host is dual stack
      and will issue a DNS query over IPv6 for an A and/or AAAA RR.

   o  The locally administered DNS server must forward customer LAN DNS
      queries using one or more of the following regardless of the
      transport of receipt for the query:




Brzozowski & Ebersman      Expires May 5, 2016                  [Page 4]


Internet-Draft                                             November 2015


   o

      A.  If the locally administered DNS server forwards DNS queries
          over IPv4 the query must be forwarded to the LAN IPv4 address
          of the customer premises router.

      B.  If the locally administered DNS server is able and configured
          to support IPv6 the DNS query must be forwarded over IPv6 and
          not to the LAN IPv4 address of the customer premises router.
          The destination DNS server IPv6 address can be learned or
          discovered in a number of ways, which is out of scope for this
          document.

      C.  To avoid using IPv4aaS for DNS queries the locally
          administered DNS server should not support DNS recursion for
          any query types.  DNS recursion relies on authoritative DNS
          server configurations, which is controlled by third parties,
          to determine the desired IP transport for DNS queries.

   o  DNS queries over IPv4 that are sent directly to the customer
      premises router must be forwarded by the customer premises router
      using DNS over IPv6 to the IPv6 DNS servers configured on the
      customer premises router.

   All original attributes of the original DNS query must remain intact
   and as-is.  The resolver receiving the DNS query must forward the
   same, over IPv6 to the target DNS server configured on the customer
   premises router.

   The DNS servers performing the DNS recursion function must have
   native IPv4 and IPv6 connectivity so they may contact authoritative
   servers of either address family.  The specification of the behavior
   for recursive DNS server is out of scope for this document.

5.  Operational Considerations

   TBP

6.  Summary

   Adhering to the above will help ensure that DNS queries over IPv4 do
   not get unnecessarily translated and more importantly are not subject
   to lengthy round trip communications to reach DNS servers over
   IPv4aaS.  Further, the use of DNS servers over IPv6 that are closer
   in proximity to the customer will help to ensure that geo-location
   accuracy remains intact.





Brzozowski & Ebersman      Expires May 5, 2016                  [Page 5]


Internet-Draft                                             November 2015


7.  IANA Considerations

   No IANA considerations are defined at this time.

8.  Security Considerations

   No additional security considerations are made in this document.

9.  Acknowledgements

   The authors would like to thank the following, in alphabetical order,
   for their contributions:

   John Berg, Kirk Erichsen, Jordan Gottlieb, John McQueen, and Dan
   Torbet

10.  Informative References

   [I-D.ietf-intarea-gre-ipv6]
              Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
              for Generic Routing Encapsulation (GRE)", draft-ietf-
              intarea-gre-ipv6-14 (work in progress), September 2015.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC7597]  Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
              Murakami, T., and T. Taylor, Ed., "Mapping of Address and
              Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/
              RFC7597, July 2015,
              <http://www.rfc-editor.org/info/rfc7597>.

   [RFC7599]  Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
              and T. Murakami, "Mapping of Address and Port using
              Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
              2015, <http://www.rfc-editor.org/info/rfc7599>.

Authors' Addresses







Brzozowski & Ebersman      Expires May 5, 2016                  [Page 6]


Internet-Draft                                             November 2015


   John Jason Brzozowski
   Comcast Cable
   1701 John F. Kennedy Blvd.
   Philadelphia, PA
   USA

   Email: john_brzozowski@cable.comcast.com


   Paul Ebersman
   Comcast Cable
   1701 John F. Kennedy Blvd.
   Philadelphia, PA
   USA

   Email: paul_ebersman@cable.comcast.com



































Brzozowski & Ebersman      Expires May 5, 2016                  [Page 7]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/