[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]