[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

Internet Engineering Task Force                                A. Yasuda
Internet-Draft                                                  I. Iwasa
Intended status: Informational                              I. Mizukoshi
Expires: January 10, 2013                                       NTT East
                                                            July 9, 2012


       Cache DNS Server Selection on the Dual-stack Home Network
                 draft-yasuda-cache-server-selection-00

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 January 10, 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 January 10, 2013                [Page 1]


Internet-Draft           Cache Server Selection                July 2012


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  3
   3.  Technology and Terminology . . . . . . . . . . . . . . . . . .  3
   4.  Network Topology . . . . . . . . . . . . . . . . . . . . . . .  3
     4.1.  Network Topology without CE  . . . . . . . . . . . . . . .  3
     4.2.  Network Topology with CE . . . . . . . . . . . . . . . . .  4
   5.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  CE Vendors Have Many Options to be Implemented . . . . . .  5
     5.2.  Many Options Complicate ISP Operation  . . . . . . . . . .  5
     5.3.  Many Options Complicate Applications Development . . . . .  5
     5.4.  CDN Don't Want Query Type/Transport Inconsistency  . . . .  6
     5.5.  IPv6/IPv4 TCP Fallback Problem . . . . . . . . . . . . . .  6
   6.  Selection Methods of Cache DNS Server  . . . . . . . . . . . .  7
     6.1.  Every Query Refers to the One IPv4 Cache DNS Server  . . .  7
     6.2.  Every Query Refers to the One IPv6 Cache DNS Server  . . .  7
     6.3.  Every Query Refers to IPv4 and IPv6 Cache DNS Server . . .  8
     6.4.  Select a DNS Server Depends on Query Type  . . . . . . . .  8
     6.5.  Select a DNS Server Depends on Transport from Clients  . .  9
   7.  The Recommended Option to Implement to CE  . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11




















Yasuda, et al.          Expires January 10, 2013                [Page 2]


Internet-Draft           Cache Server Selection                July 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 creates some problems as noted at Section 5.

   This document describes five options to solve these problems which
   are needed to modify 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.

   And when clients or CEs send both A and AAAA queries, the order of
   them is not mentioned in this document.


2.  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 [RFC2119].


3.  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.


4.  Network Topology

   This document picks up two typical topologies as dual-stack home
   network.

4.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 January 10, 2013                [Page 3]


Internet-Draft           Cache Server Selection                July 2012


             +--------------+         +--------------+
             | v4 Internet  |         | v6 Internet  |
             |              |         |              |
             |   +------+   |         |   +------+   |
             |   |v4 DNS|   |         |   |v6 DNS|   |
             |   +------+   |         |   +------+   |
             +-------+------+         +------+-------+
                     |                       |
                     |                       |
                     +-----------+-----------+
                                 |
                           +-----+-----+
                           | Client PC |
                           +-----------+


                     Home network topology without CE

                                 Figure 1

4.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 January 10, 2013                [Page 4]


Internet-Draft           Cache Server Selection                July 2012


   In this network, CE works as a proxy DNS server for clients.  Other
   configurations are same as Section 4.1.


5.  Problem Statement

   Clients or CEs refer to a cache DNS server.  Usually the address of
   the cache DNS server is set by DHCPv4[RFC2131]/v6[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.

5.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.

5.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.

5.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 January 10, 2013                [Page 5]


Internet-Draft           Cache Server Selection                July 2012


5.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

5.5.  IPv6/IPv4 TCP Fallback Problem

   When a client 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, some harmful nodes may advertise rogue RA on the IPv4
   network, and clients get IPv6 global address however they cannot
   access to the IPv6 Internet.  In this environment, application falls
   back to IPv4 if it cannot establish connection using IPv6 addresses.

   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



Yasuda, et al.          Expires January 10, 2013                [Page 6]


Internet-Draft           Cache Server Selection                July 2012


   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.


6.  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.

6.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.

6.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.

   It is not a problem that a resolver send A query to a cache DNS
   server over the IPv6 transport.[RFC4213]



Yasuda, et al.          Expires January 10, 2013                [Page 7]


Internet-Draft           Cache Server Selection                July 2012


   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.

6.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.

6.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.

   This function will be implemented on CEs.

   Pros:



Yasuda, et al.          Expires January 10, 2013                [Page 8]


Internet-Draft           Cache Server Selection                July 2012


   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.

6.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.


7.  The Recommended Option to Implement to CE

   CEs can control the connectivity between client and the Internet.
   End users and clients don't need to consider about the connectivity,
   CEs return the best DNS answer for users.

   However, if user wants to the faster response, clients or CEs SHOULD



Yasuda, et al.          Expires January 10, 2013                [Page 9]


Internet-Draft           Cache Server Selection                July 2012


   take 4th option (noted at Section 6.3).  And if user wants to the
   reliability of the connectivity to the Internet on the dual stack
   environment, clients or CEs SHOULD take 5th option (noted at
   Section 6.4).


8.  Security Considerations

   There are no new security considerations.


9.  IANA Considerations

   There are no IANA considerations.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [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.

10.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 (work in
              progress)>.



Yasuda, et al.          Expires January 10, 2013               [Page 10]


Internet-Draft           Cache Server Selection                July 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-09 (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 January 10, 2013               [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/