Internet DRAFT - draft-hazeyama-sunset4-dns-a-filter
draft-hazeyama-sunset4-dns-a-filter
Network Working Group H. Hazeyama
Internet-Draft NAIST / WIDE Project
Intended status: Informational T. Ishihara
Expires: January 11, 2014 Univ. of Tokyo / WIDE Project
O. Nakamura
Keio Univ. / WIDE Project
July 10, 2013
DNS A Record Filtering for the migration from dual stack networks to
IPv6 only networks.
draft-hazeyama-sunset4-dns-a-filter-00
Abstract
Filtering out of A records of a DNS response on a DNS proxy, we call
it ``DNS A record filtering'', is an effective and efficient solution
as a smooth migration to IPv6 only networks. DNS A record filtering
can mitigate fallback problems of dual stack nodes on IPv6 only
environment. This memo mentions the components of the DNS A record
filter solution, procedure of DNS queries and refers current issues.
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 January 11, 2014.
Copyright Notice
Copyright (c) 2013 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
Hazeyama, et al. Expires January 11, 2014 [Page 1]
Internet-Draft DNS A Record Filter July 2013
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Technology and Terminology . . . . . . . . . . . . . . . . . . 3
3. The mechanism of DNS A Record Filtering . . . . . . . . . . . 4
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. IPv6-only hosts . . . . . . . . . . . . . . . . . . . 6
3.3.2. IPv6-full-capable dual stack host . . . . . . . . . . 6
3.3.3. IPv6-partial-capable dual stack host . . . . . . . . . 7
4. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Limitation for IPv4 only applications . . . . . . . . . . 9
4.2. CNAME of the reply to an type A query . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Hazeyama, et al. Expires January 11, 2014 [Page 2]
Internet-Draft DNS A Record Filter July 2013
1. Introduction
In an IPv6 only network [RFC6586], that is composed of DHCP6 and
DNS64/NAT64, IPv4/IPv6 dual stack hosts have fallback problems due to
the partial IPv6 capability, happy eyeball functions [RFC6555],
default route on IPv4 link local address due to the link local
assumption[RFC3927], arrival timings of DNS responses, and so on.
As well as so-called DNS AAAA record filtering in IPv4 only networks,
filtering out of A records of a DNS response on a DNS proxy, we call
it ``DNS A record filter proxy'', is an effective and efficient
solution to mitigate fallback problems of dual stack nodes on IPv6
only environment.
DNS A record filtering solution allows dual stack nodes to resolve
names both by IPv4 and IPv6 by notifying the IPv4 address of an DNS A
record filter proxy through DHCP4 and the IPv6 address of the DNS A
record filter proxy through DHCP6. On the other hand, a DNS A record
filter proxy forces dual stack nodes to conduct actual communications
after the name query procedure through IPv6, by telling only AAAA or
NAT64 mapped AAAA records to dual stack nodes. In this solution, no
special action is required on dual stack nodes. A network operator
can choose DNS64 and NAT64 location along with their design policy.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Technology and Terminology
In this document, the following terms are used. "Dual Stack" refers
to a technique for providing complete support for both Internet
protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213].
"NAT64" refers to a Network Address Translator - Protocol Translator
defined in [RFC6052], [RFC6144], [RFC6145], [RFC6146], [RFC6384].
"DNS64" refers DNS extensions to use NAT64 translation from IPv6
clients to IPv4 servers with name resolution mechanisms that is
defined in [RFC6147].
"DHCP4" refers Dynamic Host Configuration Protocol for IPv4 that is
defined in [RFC2131].
"DHCP6" refers Dynamic Host Configuration Protocol for IPv6. So
Hazeyama, et al. Expires January 11, 2014 [Page 3]
Internet-Draft DNS A Record Filter July 2013
called "Stateful DHCP6" is defined in [RFC3315] and "Stateless DHCP6"
is defined in [RFC3736]. "DHCP-PD" or "DHCPv6 Prefix Delegation"
refers IPv6 Prefix Options for DHCP6 that is initially defined in
[RFC3633] and updated in [RFC6603].
"ND" refers Neighbor Discovery for IP version 6 (IPv6) that is
defined in [RFC4861] and updated in [RFC5942].
3. The mechanism of DNS A Record Filtering
3.1. Assumptions
The DNS A record filtering simply filters out ``A record'' entry of a
DNS reply on a DNS proxy. As our assumption, the DNS A record
filtering solution is mainly used in an IPv6 only network by
combining DNS64/NAT64, DHCP4 and DHCP6.
We also assume that hosts are dual stack capable, that is, hosts have
ND function and the IPv6 address assignment function by RA at least.
Stateful DHCP6, Stateless DHCP6 and IPv6 DNS query functions are
preferable to be equipped by hosts.
3.2. Components
The components of the network, where this DNS A record filtering is
employed, are as follows;
o DHCP4 server: this DHCP4 server offers a private IPv4 address to
mitigate the long fall back problem due to the IPv4 link local
assumption. The DHCP4 server also offers the IPv4 address of the
DNS A record filter proxy. To avoid the selection of the IPv4 by
Happy Eyeball [RFC6555] in a dual stack host, this DHCP4 server
MUST NOT provide the IPv4 default route.
o DHCP6 server: this DHCP6 server MUST provide the IPv6 address of
the DNS A record filter proxy. Both stateful DHCP6 and stateless
DHCP6 can be employed. If the subnet is composed of a security
switch and/or security wi-fi controllers, stateful DHCP6 is prefer
to avoid the blocking due to the multiple temporary IPv6 address
on a host.
o DNS A record filter proxy : this DNS proxy is the key component of
this solution. The DNS proxy SHOULD be located on the leaf
subnet. The DNS proxy has a private IPv4 address that SHOULD be
the same subnet address provided by the DHCP4. The DNS proxy has
an IPv6 address that is announced to hosts through DHCP6.
Hazeyama, et al. Expires January 11, 2014 [Page 4]
Internet-Draft DNS A Record Filter July 2013
o DNS64 server : at least, one DNS64 server is required. The DNS A
record filter proxy forwards all queries to this DNS64 server
directly, or several DNS forwarder can be placed for load
balancing of DNS64 servers
o Authoritative DNS servers : these authoritative DNS servers would
be queried by DNS64 servers. These authoritative DNS servers MUST
NOT return inappropriate replies mentioned in [RFC4074] to kick
the fallback function of DNS64 servers
o NAT64 translators : at least, one NAT64 translator is placed that
can be reached by hosts through IPv6. A NAT64 translator can be
settled as the gateway of the leaf subnet, or an aggregated
translator of the intra network, or a global reachable open
translator. Several NAT64 translators can be registered in DNS64
servers for the load balancing or for handling different IPv4
prefixes by each NAT64 translrator.
Figure 1 shows a sample network topology of this solution.
+-----------------+
|Authoritative DNS|
+-----------------+
|
+------ IPv6 Internet ------+ +---- IPv4 Internet ---+
| |
+--------------+ +-------+ +------+
| IPv6 router | | DNS64 | | NAT64|
+--------------+ +-------+ +------+
| | |
+--------------- IPv6 backbone ----------------------+
|
+----------+ +-----------+ +--------+ +--------+
| A Record | | IPv6 | | DHCP6 | | DHCP4 |
| Filter | | Router | | server | | server |
| Proxy | +-----------+ +--------+ +--------+
+----------+ | | |
| | | |
+--- /64 prefix segment, closed private IPv4 segment ------+
| |
| |
+----------------+ +------------------+
|ipv6-only hosts | | dual stack hosts |
+----------------+ +------------------+
A sample network topology of DNS A record filtering
Hazeyama, et al. Expires January 11, 2014 [Page 5]
Internet-Draft DNS A Record Filter July 2013
Figure 1
3.3. Procedure
3.3.1. IPv6-only hosts
The procedure on IPv6-only hosts is as follows;
o The host connects to the leaf subnet in layer 2 level.
o The host gets global IPv6 address through RA or stateful DHCP6,
and also learns the IPv6 address of the DNS A record filter proxy.
o When the host connects to an URL, the hosts queries by type ANY or
by type AAAA to the DNS A record filter proxy through IPv6.
o The DNS A record filter proxy forwards the received the type ANY
query to the upper DNS forwarder or DNS64 server.
o When the DNS64 server receives the query, the DNS64 server
forwards the issued FQDN to the upper authoritative DNS.
* If the FQDN has AAAA record, the DNS64 returns AAAA record to
the DNS A record filter proxy.
* If the FQDN has only A record, the DNS64 returns NAT64 prefix
mapped AAAA record to the DNS A record filter proxy.
* The DNS64 server or the upper DNS forwarder may return A record
to the DNS A record filter proxy with AAAA record.
o When the DNS A record filter proxy receives the reply, the DNS A
record filter proxy filters out A record if the reply contains A
record.
o The DNS A record filter proxy returns only AAAA records to the
host.
o The host access to the issued URL through the IPv6 address of the
destination or the NAT64 prefix mapped address.
3.3.2. IPv6-full-capable dual stack host
An IPv6-full-capable dual stack node equips DHCP6 function and IPv6
DNS query function, therefore, IPv6-full-capable dual stack node can
send DNS queries through both IPv4 and IPv6.
The procedure on IPv6-full-capable dual stack hosts (like Windows 7,
Hazeyama, et al. Expires January 11, 2014 [Page 6]
Internet-Draft DNS A Record Filter July 2013
etc.) is as follows;
o The host connects to the leaf subnet in layer 2 level.
o The host gets a global IPv6 address through RA or stateful DHCP6,
and also learns the IPv6 address of the DNS A record filter proxy.
o The host also gets a private IPv4 address through DHCP4, and also
learns the IPv4 address of the DNS A record filter proxy.
o The network connectivity check sequence of the Operating System
may run, then, IPv6 will be selected on the host because the IPv4
is not global reachable.
o When the host connects to an URL, the host queries by type ANY to
the DNS A record filter proxy through IPv6.
o The DNS A record filter proxy forwards the received type ANY query
to the upper DNS forwarder or DNS64 server.
o When the DNS64 server receives the query, the DNS64 server
forwards the issued FQDN to the upper authoritative DNS.
* If the FQDN has AAAA record, the DNS64 returns AAAA record to
the DNS A record filter proxy.
* If the FQDN has only A record, the DNS64 returns NAT64 prefix
mapped AAAA record to the DNS A record filter proxy.
* The DNS64 server or the upper DNS forwarder may return A record
to the DNS A record filter proxy with AAAA record.
o When the DNS A record filter proxy receives the reply, the DNS A
record filter proxy filters out A record if the reply contains A
record.
o The DNS A record filter proxy returns only AAAA records to the
host.
o The host access to the issued URL by using the IPv6 address of the
destination or the NAT64 prefix mapped address.
3.3.3. IPv6-partial-capable dual stack host
An IPv6-partial-capable dual stack node does not equip either DHCP6
function or IPv6 DNS query function, therefore, IPv6-partial-capable
dual stack node will send DNS queries through only IPv4. However,
IPv6-partial-capable dual stack can recognize AAAA record or IPv6
Hazeyama, et al. Expires January 11, 2014 [Page 7]
Internet-Draft DNS A Record Filter July 2013
address.
The procedure on IPv6-partial-capable dual stack host is as follows;
o The host connects to the leaf subnet in layer 2 level.
o The host gets a global IPv6 address through RA.
o The host also gets a private IPv4 address through DHCP4, and also
learns the IPv4 address of the DNS A record filter proxy.
o The network connectivity check sequence of the Operating System
may run, then, IPv6 may be selected on the IPv6-preferred host
because the IPv4 is not global reachable. In some case, the
network connectivity check may pass by name resolution to the
anchor server, or the network connectivity may run again with
certain interval.
o When the host connects to an URL, the host queries by type ANY to
the DNS A record filter proxy through IPv4.
o The DNS A record filter proxy forwards the received type ANY query
to the upper DNS forwarder or DNS64 server through IPv6.
o When the DNS64 server receives the query, the DNS64 server
forwards the issued FQDN to the upper authoritative DNS.
* If the FQDN has AAAA record, the DNS64 returns AAAA record to
the DNS A record filter proxy.
* If the FQDN has only A record, the DNS64 returns NAT64 prefix
mapped AAAA record to the DNS A record filter proxy.
* The DNS64 server or the upper DNS forwarder may return A record
to the DNS A record filter proxy with AAAA record.
o When the DNS A record filter proxy receives the reply, the DNS A
record filter proxy filter out A record if the reply contains A
record.
o The DNS A record filter proxy returns only AAAA records to the
host.
o The host access to the issued URL by using the IPv6 address of the
destination or the NAT64 prefix mapped address.
Hazeyama, et al. Expires January 11, 2014 [Page 8]
Internet-Draft DNS A Record Filter July 2013
4. Discussions
4.1. Limitation for IPv4 only applications
As mentioned in [RFC6586], IPv4-only (or IPv6-incapable) applications
exist. Such IPv4-only applications will not work on this DNS A
record filtering environment. It is preferable that such IPv4-only
applications become dual stack applications if possible.
4.2. CNAME of the reply to an type A query
We conducted a field trial of this DNS A record filter solution in
Interop Tokyo 2013. We provided an IPv6-only Wi-Fi access with this
DNS A record filter solution. We used the current Debian release and
bind 9.9.2-p1 patch provided from WIDE project as the DNS A Record
filter proxy.
In the hot stage of Interop Tokyo 2013, we met a trouble case of the
current DNS A record filter. In the trouble case, a host used
Firefox browser and crawled several web pages for test. In some web
page, several contents were lost. We inspected by packet captures,
the reply of the A query to the host arrived faster than the arrival
of the reply of AAAA record. The reply of A query contained as type
CNAME, that was not filtered in the current bind A filter patch.
(The A filter patch removed type A record of the CNAME.) On the
other hand, in a successful case, the reply of AAAA record, that
contained type CNAME and type AAAA of the CNAME, arrived faster than
the type A reply.
Of course, we have to conduct further investigation and tests, the
CNAME on a type A reply would be removed by DNS A filter proxy as
well as type A record on the type A reply.
5. Security Considerations
As well as mentioned in [RFC6586], the use of IPv6 instead of IPv4 by
itself does not make a big security difference.
6. IANA Considerations
This document has no IANA implications.
7. References
Hazeyama, et al. Expires January 11, 2014 [Page 9]
Internet-Draft DNS A Record Filter July 2013
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
7.2. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
Model: The Relationship between Links and Subnet
Prefixes", RFC 5942, July 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
Hazeyama, et al. Expires January 11, 2014 [Page 10]
Internet-Draft DNS A Record Filter July 2013
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011.
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG)
for IPv6-to-IPv4 Translation", RFC 6384, October 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.
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan,
"Prefix Exclude Option for DHCPv6-based Prefix
Delegation", RFC 6603, May 2012.
Appendix A. Acknowledgments
T. Jinmei of Internet Systems Consortium for providing DNS A filter
patch of Bind 9.
O. Onoe of Sony Corporation for his deep inspection and testing of
end node devices in WIDE project meeting in September 2012.
Interop Tokyo 2013 NOC members and Nano Opt Media for providing a
field trial of this DNS A Record Filter solution as a service
network. Especially, K. Mano of A10 Networks and STM members for
their deep inspection and testing.
Authors' Addresses
Hiroaki Hazeyama
NAIST / WIDE Project
Takayama 8916-5
Nara,
Japan
Phone: +81 743 72 5216
Email: hiroa-ha@is.naist.jp
Hazeyama, et al. Expires January 11, 2014 [Page 11]
Internet-Draft DNS A Record Filter July 2013
Tomohiro Ishihara
Univ. of Tokyo / WIDE Project
3-8-1 Komaba, Meguro
Tokyo,
Japan
Email: sho@c.u-tokyo.ac.jp
Osamu Nakamura
Keio Univ. / WIDE Project
5322 Endo
Kanagawa,
Japan
Email: osamu@wide.ad.jp
Hazeyama, et al. Expires January 11, 2014 [Page 12]
