Internet DRAFT - draft-jjmb-sunset4-dns-forwarding-ipv4aas
draft-jjmb-sunset4-dns-forwarding-ipv4aas
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]
