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


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

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 ( 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

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

3. Topology

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

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:

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:

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:

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


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

[I-D.ietf-intarea-gre-ipv6] Pignataro, C., Bonica, R. and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", Internet-Draft draft-ietf-intarea-gre-ipv6-14, September 2015.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987.
[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.
[RFC7597] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T. and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015.
[RFC7599] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S. and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015.

Authors' Addresses

John Jason Brzozowski Comcast Cable 1701 John F. Kennedy Blvd. Philadelphia, PA USA EMail:
Paul Ebersman Comcast Cable 1701 John F. Kennedy Blvd. Philadelphia, PA USA EMail: