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.

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

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.

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

• CG-NAT - Carrier Grade Network Address Translation for IPv4
• 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:

• Dual stack customer premise LAN
• Single stack IPv6 only customer WAN
• RFC1918 addressing is utilized for IPv4
• Globally routable IPv6 is delegated and assigned to the customer premises router
• 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.

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:

• 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.
• 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.
• 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:

• Added round trip for DNS over IPv4 over the IPv4aaS infrastructure
• Less accurate, coarse grained geo-location information
• 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:

• 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.
• 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:
• 1. 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.
  2. 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.
  3. 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.
• 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.

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

Authors' Addresses