Internet DRAFT - draft-yasuda-cache-server-selection
draft-yasuda-cache-server-selection
Internet Engineering Task Force A. Yasuda
Internet-Draft I. Iwasa
Intended status: Informational I. Mizukoshi
Expires: April 17, 2013 NTT East
October 14, 2012
Cache DNS Server Selection on the Dual-stack Home Network
draft-yasuda-cache-server-selection-01
Abstract
This document suggests two methods to select a cache DNS server on
the clients or CEs. Several options to select a cache DNS server are
implemented on clients or CEs, and this situation causes some
problems and troubles. This document describes merits and demerits
of these options, and suggests two preferred methods of the cache DNS
server selection.
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 April 17, 2013.
Copyright Notice
Copyright (c) 2012 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
Yasuda, et al. Expires April 17, 2013 [Page 1]
Internet-Draft Cache Server Selection October 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Technology and Terminology . . . . . . . . . . . . . . . . . . 3
3. Network Topology . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Network Topology without CE . . . . . . . . . . . . . . . 3
3.2. Network Topology with CE . . . . . . . . . . . . . . . . . 4
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4.1. CE Vendors Have Many Options to be Implemented . . . . . . 5
4.2. Many Options Complicate ISP Operation . . . . . . . . . . 5
4.3. Many Options Complicate Applications Development . . . . . 5
4.4. CDN Don't Want Query Type/Transport Inconsistency . . . . 6
4.5. IPv6/IPv4 TCP Fallback Problem . . . . . . . . . . . . . . 6
5. Selection Methods of Cache DNS Server . . . . . . . . . . . . 7
5.1. Every Query Refers to the One IPv4 Cache DNS Server . . . 7
5.2. Every Query Refers to the One IPv6 Cache DNS Server . . . 7
5.3. Every Query Refers to IPv4 and IPv6 Cache DNS Server . . . 8
5.4. Select a DNS Server Depends on Query Type . . . . . . . . 8
5.5. Select a DNS Server Depends on Transport from Clients . . 9
6. The Recommended Option to Implement to CE . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Yasuda, et al. Expires April 17, 2013 [Page 2]
Internet-Draft Cache Server Selection October 2012
1. Introduction
When clients or CEs know several IP addresses of IPv4 DNS servers and
IPv6 DNS servers in the home network environment, there is no rule in
a cache DNS server selection method that clients or CEs refer to.
The selection method depends on implementations of clients or CEs.
This situation causes some problems as noted at Section 4.
This document describes five methods for solving these problems by
modifying only clients and/or CEs. By adopting these methods to
clients or CEs, it is possible to optimize the procedure to resolve
names in this situation. Finally, two methods are recommended.
2. Technology and Terminology
CE: Equipment which is installed in a user's home network such as
Broadband Router or Home Gateway. The basic features are required
by [I-D.ietf-v6ops-6204bis], and the design considerations are
described in [I-D.donley-v6ops-ce-router-design].
v4 DNS: Cache DNS server which has A RR and AAAA RR, and accept IPv4
transport only.
v6 DNS: Cache DNS server which has A RR and AAAA RR, and accept IPv6
transport only.
3. Network Topology
This document picks up two typical topologies as dual-stack home
network.
3.1. Network Topology without CE
A client PC connects directly to the both IPv4 and IPv6 Internet.
This topology is composed without CE.
Yasuda, et al. Expires April 17, 2013 [Page 3]
Internet-Draft Cache Server Selection October 2012
+--------------+ +--------------+
| v4 Internet | | v6 Internet |
| | | |
| +------+ | | +------+ |
| |v4 DNS| | | |v6 DNS| |
| +------+ | | +------+ |
+-------+------+ +------+-------+
| |
| |
+-----------+-----------+
|
+-----+-----+
| Client PC |
+-----------+
Home network topology without CE
Figure 1
3.2. Network Topology with CE
A client PC connects to both IPv4 and IPv6 Internet through a CE.
+--------------+ +--------------+
| v4 Internet | | v6 Internet |
| | | |
| +------+ | | +------+ |
| |v4 DNS| | | |v6 DNS| |
| +------+ | | +------+ |
+-------+------+ +------+-------+
| |
| |
+-----------+-----------+
|
+--+--+
| CE |
+--+--+
|
+-----+-----+
| Client PC |
+-----------+
Home network topology with CE
Figure 2
Yasuda, et al. Expires April 17, 2013 [Page 4]
Internet-Draft Cache Server Selection October 2012
In this network, CE works as a proxy DNS server for clients. Other
configurations are same as Section 3.1.
4. Problem Statement
Clients or CEs always refer to a cache DNS server. Usually the
address of the cache DNS server is set by DHCPv4[RFC2131] and
DHCPv6[RFC3315], RA[RFC6106] or manually. At that time, clients or
CEs know two or more different DNS servers' addresses of IPv4 and
IPv6.
There are no standards or guidelines that indicates which DNS server
is referred to and how it is selected on the clients or CEs. Thus
there are some implementations of DNS selection method on the clients
or CEs.
The viewpoints of the problems are described as follows.
4.1. CE Vendors Have Many Options to be Implemented
o It is not efficient for vendors to implement all the options.
o Users need to select one option if vendor implements many options,
and it's not realistic to require users to select one option.
4.2. Many Options Complicate ISP Operation
When there are several options to select a cache DNS server on
clients and CEs, ISPs or network operators have to adjust each option
to operate comfortably.
o If the queries go to one cache DNS server, the load of the DNS
servers is on one side.
o If CEs send queries to both IPv4 DNS and IPv6 DNS, ISP will
receive twice as many queries as current.
4.3. Many Options Complicate Applications Development
When a user accesses to the same target by some clients, the
behaviors are different according to the implementations of clients
or CEs.
It is a critical issue for application developers.
Yasuda, et al. Expires April 17, 2013 [Page 5]
Internet-Draft Cache Server Selection October 2012
4.4. CDN Don't Want Query Type/Transport Inconsistency
CDN providers control their own traffic by returning different
address of contents servers for every cache DNS server. When the
queries from CEs are on one side, CDN providers cannot control the
contents delivery traffic well.
+------+ +---------+ +-----------+
|client| -> |cache DNS| -> | | www.example.com
+------+ <= +---------+ <= | |
S1 S1 | | +----+
+---------+ | | | S1 |
|cache DNS| -> | | +----+
+---------+ <= | contents |
S2 | DNS | +----+
+------+ +---------+ | | | S2 |
|client| -> |cache DNS| -> | | +----+
+------+ <= +---------+ <= | |
S1 S1 | | +----+
+---------+ | | | S3 |
|cache DNS| -> | | +----+
+---------+ <= +-----------+
S3
-> : query
<= : answer
Sx : contents server
Traffic control of using DNS on CDN
Figure 3
4.5. IPv6/IPv4 TCP Fallback Problem
When a client's network is adapted for IPv6 and an ISP doesn't have
global reachability to the IPv6 Internet because of some reasons,
IPv6/IPv4 TCP fallback problem which is stated at [RFC4074] and
[RFC4472] occurs.
For example, assuming a scenario, one client doesn't have a
connectivity to the IPv6 Internet, and a harmful node advertises
rogue RA to the client. At that time, the client gets IPv6 global
prefix and tries to connect to the IPv6 Internet by using IPv6. But
it cannot access to the IPv6 Internet, then the client falls back to
IPv4.
Yasuda, et al. Expires April 17, 2013 [Page 6]
Internet-Draft Cache Server Selection October 2012
If taking a method which doesn't answer AAAA record when a client has
no connectivity to the IPv6 Internet, the IPv6/IPv4 TCP fallback
problem doesn't occur in any environment.
To solve this problem, CEs will return an answer only available
transport records to users. By returning an answer only available
transport, clients decline to access to the destination on the
transport which doesn't have a connectivity to the Internet.
5. Selection Methods of Cache DNS Server
In this section, five different options are described as a method of
referring to a cache DNS server to solve the problems.
5.1. Every Query Refers to the One IPv4 Cache DNS Server
The referred cache DNS server is fixed to IPv4 DNS regardless of the
query type which is A or AAAA. When clients refer to an IPv4 cache
DNS server, also fix the using transport protocol as IPv4.
This function will be implemented on clients or CEs.
It is not a problem to send an AAAA query to a cache DNS server on
the IPv4 transport.[RFC4213]
Pros:
o The behavior is simple, troubleshooting is easier than other
options generally.
Cons:
o The mismatch between RR type and transport arises.
o When a client refers IPv6 query to an IPv4 DNS, some troubles on
the IPv4 network influence the IPv6 network.
o This method is against deployment of IPv6 in the world.
5.2. Every Query Refers to the One IPv6 Cache DNS Server
The referred DNS server is fixed to IPv6 DNS regardless of the query
type which is A or AAAA. When clients refer to an IPv6 cache DNS
server, also fix the using transport protocol as IPv6.
This function will be implemented on clients or CEs.
Yasuda, et al. Expires April 17, 2013 [Page 7]
Internet-Draft Cache Server Selection October 2012
It is not a problem that a resolver send A query to a cache DNS
server over the IPv6 transport.[RFC4213]
Pros:
o The behavior is simple, troubleshooting is easier than other
options generally.
Cons:
o The mismatch between RR type and transport arises.
o When a client refers IPv4 query to an IPv6 DNS, some troubles on
the IPv6 network influence the IPv4 network.
o There are bad influences to users who don't have IPv6 connectivity
to the IPv6 Internet.
5.3. Every Query Refers to IPv4 and IPv6 Cache DNS Server
Clients and CEs send query to both IPv4 and IPv6 cache DNS servers at
same time. When clients or CEs send to IPv4 DNS, use IPv4 transport.
When clients or CEs send to IPv6 DNS, use IPv6 transport. The answer
which returns faster is used for a client.
This function will be implemented on clients or CEs.
Pros:
o The response time is to be faster.
o IPv6/IPv4 TCP fallback problem will be solved.
Cons:
o The number of queries increases twice.
o Referred DNS server is not constant.
5.4. Select a DNS Server Depends on Query Type
The transport protocol from a CE to a cache DNS server depends on the
query type from clients to a CE. The CE maps query type onto a
transport protocol toward a cache DNS server. When the query type
from a client is A RR, the CE uses IPv4 transport to the IPv4 cache
DNS server. When the query type from a client is AAAA RR, the CE
uses IPv6 transport to the IPv6 cache DNS server.
Yasuda, et al. Expires April 17, 2013 [Page 8]
Internet-Draft Cache Server Selection October 2012
This function will be implemented on CEs.
Pros:
o IPv6/IPv4 TCP fallback problem will be solved.
Cons:
o Other query types need to be considered about to be able to handle
them.
o IPv6 network topology is not same as IPv4 network, so it is not
appropriate for depending on the query type.
The relationship between a query and a transport protocol is stated
in [RFC3596] Section 1:
The IP protocol version used for querying resource records is
independent of the protocol version of the resource records; e.g.,
IPv4 transport can be used to query IPv6 records and vice versa.
A query type and a transport protocol are independent, and it is not
a problem that a transport protocol depends on a query type.
5.5. Select a DNS Server Depends on Transport from Clients
DNS server which is selected depends on the transport protocol from
clients to CEs. When the transport is IPv4, CE selects IPv4 DNS
server. When the transport is IPv6, CE selects IPv6 DNS server.
Pros:
o A client and a CE select same DNS server.
Cons:
o The mismatch between RR type and transport arises.
o When ISP networks become native IPv6, but home network is still
IPv4, user cannot access to the destination.
o All queries from clients which doesn't have IPv6 transport for
DNS, like Windows XP, go to IPv4 DNS.
Yasuda, et al. Expires April 17, 2013 [Page 9]
Internet-Draft Cache Server Selection October 2012
6. The Recommended Option to Implement to CE
According to above discussion, this document recommends two selection
methods of cache DNS servers. First method, which is noted at
Section 5.3, is that a CE sends queries to both IPv4 and IPv6 cache
DNS servers at same time. Second recommended method is noted at
Section 5.4, which indicates that a CE selects a cache DNS server
depends on query type from a client.
7. Security Considerations
There are no new security considerations.
8. IANA Considerations
There are no IANA considerations.
9. References
9.1. Normative 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.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 6106, November 2010.
9.2. Informative References
[I-D.donley-v6ops-ce-router-design]
Donley, C., Brzozowski, J., Liu, H., Kuarsingh, V., and J.
Weil, "Design Considerations for an IPv6 CE Router", March
2012, <draft-donley-v6ops-ce-router-design-00 (expired)>.
Yasuda, et al. Expires April 17, 2013 [Page 10]
Internet-Draft Cache Server Selection October 2012
[I-D.ietf-v6ops-6204bis]
Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", May 2012,
<draft-ietf-v6ops-6204bis-11 (work in progress)>.
[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472,
April 2006.
Authors' Addresses
Ayumu Yasuda
NTT East
3-19-2 Nishi Shinjuku, Shinjuku-ku
Tokyo,
Japan
Email: a.yasuda@east.ntt.co.jp
Isao Iwasa
NTT East
3-19-2 Nishi Shinjuku, Shinjuku-ku
Tokyo,
Japan
Email: i.iwasa@east.ntt.co.jp
Ichiro Mizukoshi
NTT East
3-19-2 Nishi Shinjuku, Shinjuku-ku
Tokyo,
Japan
Email: i.mizukoshi@east.ntt.co.jp
Yasuda, et al. Expires April 17, 2013 [Page 11]
