Co-existence of both dual-stack and IPv6-only hosts
draft-kaliwoda-sunset4-dual-ipv6-coexist-00

SUNSET4                                                      A. Kaliwoda
Internet-Draft                                                     Cisco
Intended status: Informational                        September 12, 2012
Expires: March 16, 2013

          Co-existence of both dual-stack and IPv6-only hosts
              draft-kaliwoda-sunset4-dual-ipv6-coexist-00

Abstract

   Some networks are expected to support IPv4-only, dual-stack, and
   IPv6-only hosts at the same time.  Such networks may want to add
   IPv6/IPv4 translation for the IPv6-only host so it can access servers
   on the IPv4 Internet.  Adding translation service to the IPv6-enabled
   network may change dual-stack host behavior and affect the way
   deployed network is working.  This document defines the problem
   statement for such networks.

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 March 16, 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

Kaliwoda                 Expires March 16, 2013                 [Page 1]
Internet-Draft    Dual-stack and IPv6-only coexistence    September 2012

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Host behavior analysis  . . . . . . . . . . . . . . . . . . . . 3
   5.  Impact analysis . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6

Kaliwoda                 Expires March 16, 2013                 [Page 2]
Internet-Draft    Dual-stack and IPv6-only coexistence    September 2012

1.  Introduction

   Many networks are undergoing the transition to IPv6, and need to also
   provide IPv4 connectivity and handle IPv4 exhaustion.  Initially, the
   service offered to residential (wireline/cable) consumers will be
   dual IP stack while the access and transport network may be either
   dual stack or considered IPv6 only in 4over6 family of solutions.

   Eventually, the service provider would like to provide IPv6/IPv4
   translation service in order to allow IPv6-only hosts to access IPv4-
   only Internet resources.

2.  Problem Statement

   Addition of IPv6/IPv4 translation service is for IPv6-only hosts to
   allow them accessing IPv4-only servers.  It may be assumed and
   expected that IPv4-only and dual-stack hosts are not influenced by
   the translation service and they access IPv4-only Internet resources
   the same way as before.

   While it is true for IPv4-only devices, dual-stack devices may be
   affected and their access to IPv4 Internet may be changed.

3.  DNS64

   IPv6-only host needs to perform DNS query to a DNS64 recursive
   resolver in order to use IPv6/IPv4 translator and get access to IPv4-
   only server.  IPv6 address of DNS64 needs to be dynamically
   provisioned on the IPv6-only host.

   DNS IPv6 address information is provided dynamically via DHCPv6 or
   stateless autoconfiguration to all IPv6-ready hosts in the same way
   i.e. both IPv6-only and dual-stack host will be using the same IPv6
   DNS address to resolve FQDN, unless special measures are taken
   [I-D.wing-behave-dns64-config]

4.  Host behavior analysis

   Let's assume that host initiates IP connection to the IPv4-only
   server identified with FQDN, where FQDN has only A RR defined in the
   DNS servers.

   IPv4-only host behavior:

Kaliwoda                 Expires March 16, 2013                 [Page 3]
Internet-Draft    Dual-stack and IPv6-only coexistence    September 2012

   o  With a normal DNS server, IPv4-only host sends an A query to DNS
      server using IPv4 transport, resolves IPv4 address of the server
      and initiates the session from its IPv4 stack.

   o  With a DNS64 server, the behavior is exactly the same since DNS64
      extensions are not invoked for an A query.

   Dual-stack host behavior:

   o  With a normal DNS server, dual-stack host sends query to DNS
      server using either IPv4 or IPv6 transport.  In either case it
      sends both an A and an AAAA query.  Since the assumption is that
      FQDN being resolved has only A RR defined, host should always
      resolve IPv4 address only of the server.  It will initiate the
      session from its IPv4 stack.

   o  With a DNS64 server, the response to a query is different since it
      will include the synthetized AAAA record rather than A record
      only.  As the consequence, according to [RFC3484] the host may
      initiate the session from its IPv6 stack and such session will be
      forwarded via NAT64 translation device.

   IP6-only host behavior:

   o  With a normal DNS server, IPv6-only host sends an AAAA query to
      DNS server using IPv6 transport.  Host should not resolve the FQDN
      of IPv4-only server since there is no AAAA RR defined.

   o  With a DNS64 server, IPv6-only host should receive synthetized
      AAAA response based on the A record DNS64 resolved.  IPv6 session
      will work via NAT64 translation device.

   It is possible that Service Provider will add separate DNS server
   specifically to run DNS64 extensions and leave another DNS server
   unchanged.  In such case, the name resolution outcome of the dual-
   stack host may be dependant on which DNS server is being contacted.

   o  If dual-stack host sends request over IPv4 transport, the request
      will be responded by normal DNS server with A record only.

   o  If dual-stack hosts sends request over IPv6 transport, the request
      will be responded by DNS64 server and it will contain syntetized
      AAAA response.

   In summary, the dual-stack host name resolution result can be
   affected by adding DNS64 service.  As the consequence the way dual-
   stack hosts communicates with IPv4-only server may be affected since
   the source address selection according to [RFC3484] is impacted and

Kaliwoda                 Expires March 16, 2013                 [Page 4]
Internet-Draft    Dual-stack and IPv6-only coexistence    September 2012

   eventually dual-stack host may no longer take the IPv4 path i.e. will
   not initiate the session from its IPv4 stack that may be forwarded
   via NAT44 engine; but it will rather take IPv6/IPv4 translated path
   originated from its IPv6 stack.

5.  Impact analysis

   The possible change of IPv4 forwarding path of dual-stack host can be
   seen as the side effect of adding IPv6/IPv4 translation service and
   it may be highly undesired.

   There are few reasons why:

   o  The goal is to help IPv6-only devices to get access to v4 Internet
      and not to disrupt or alter the IPv4 service

   o  SP does not control and does not know what IPv4 forwarding path is
      to be taken by dual-stack end devices.  It increases the
      operational complexity e.g. when solving connectivity problem.

   o  IPv4 exhaust may not be a problem in the Service Provider network.
      In such case outbound session to IPv4 servers initiated by IPv4-
      ready host is not supposed to be NATed in the SP network.  In case
      dual-stack device initiates session via IPv6/IPv4 translator, the
      traffic passes stateful NAT64 and it may impact the session.

   o  IPv6/IPv4 translation (NAT64) may have different NAT
      characteristics compared with deployed NAT44 solution e.g.
      different ALG implemented.  For example if NAT44 supports ALG that
      NAT64 does not support, the communication of dual-stack device
      with IPv4-only server may be dependant on which NAT engine it goes
      through.  Even in the case of FTP application, FTP64 ALG is not
      exactly the same as FTP ALG.  Thus switching the v4 path may break
      some applications and may have operational impact.

   o  Troubleshooting of IPv4 connectivity, monitoring of NAT44
      resources, operational procedures, technical support; needs to be
      adjusted to handle the possible change of IPv4 forwarding path
      through the SP network

   Another important consequence of providing DNS64 information to the
   host is that if affects the scaling of the network design and may
   lead to suboptimum (in terms of hardware resources and address usage)
   and thus costly solution.  This is based on the following reasoning:

   o  Stateful NAT engine is scaled for given peak traffic and has IPv4
      public resource of X assigned.  Traffic through the NAT engine

Kaliwoda                 Expires March 16, 2013                 [Page 5]
Internet-Draft    Dual-stack and IPv6-only coexistence    September 2012

      represents the bidirectional traffic with IPv4-only servers and it
      says nothing about IP stack support of the host i.e. it can be
      IPv4-only or dual-stack host.

   o  When DNS64 information is distributed, dual-stack device may take
      either NAT44 path or IPv6/IPv4 translated path, depending on the
      host behavior or the way DNS64 is enabled in the network.

   o  Since the IPv4 path selection is not fully deterministic from the
      Service Provider perspective i.e. it may depend on the host
      behavior; NAT44 engine reserved resources (HW, address pools)
      should stay the same in case traffic from dual-stack hosts keeps
      the same forwarding path.  On the other hand stateful NAT64 should
      be scaled not only for the traffic from IPv6-only hosts but should
      be also ready to take some traffic from dual-stack hosts.

   As such it can be expected that the resources for NAT44 and NAT64
   will not be optimally used.

   The goal is to find the solution that will allow introducing IPv6/
   IPv4 translation service to IPv6-only hosts while keeping dual-stack
   hosts unaffected.

6.  Security Considerations

   This document does not yet discuss security-related issues.

7.  Normative References

   [I-D.wing-behave-dns64-config]
              Wing, D., "IPv6-only and Dual Stack Hosts on the Same
              Network with DNS64", draft-wing-behave-dns64-config-03
              (work in progress), February 2011.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

Kaliwoda                 Expires March 16, 2013                 [Page 6]
Internet-Draft    Dual-stack and IPv6-only coexistence    September 2012

Author's Address

   Arkadiusz Kaliwoda
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Email: akaliwod@cisco.com

Kaliwoda                 Expires March 16, 2013                 [Page 7]