[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

SUNSET4                                                      A. Kaliwoda
Internet-Draft                                                     Cisco
Intended status: Informational                                  D. Binet
Expires: April 8, 2013                             France Telecom Orange
                                                         October 5, 2012


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

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 April 8, 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



Kaliwoda & Binet          Expires April 8, 2013                 [Page 1]


Internet-Draft    Dual-stack and IPv6-only coexistence      October 2012


   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
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Host behavior analysis  . . . . . . . . . . . . . . . . . . . . 3
   5.  Impacted Service Provider networks  . . . . . . . . . . . . . . 5
   6.  Impact analysis . . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9


































Kaliwoda & Binet          Expires April 8, 2013                 [Page 2]


Internet-Draft    Dual-stack and IPv6-only coexistence      October 2012


1.  Introduction

   Many networks are undergoing the transition to IPv6.  Whatever
   transition method is selected by the Service Provider, the main
   challenge is to maintain IPv4 access service with minimized quality
   of experience impact for the customers.  It can be expected that
   access to IPv4 only servers from IPv4-only hosts or dual-stack hosts
   may be impacted by IPv4 addresses exhaust problem and IPv4 port
   sharing solution.  In case of IPv6-only hosts the Service Provider is
   likely to provide IPv6/IPv4 translation service in order to maintain
   IPv4 service continuity.


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 without affecting the quality of experience of
   the customer.

   While it is true that for IPv4-only devices, IPv4-only Internet
   resources access will not be impacted by DNS64/NAT64 service
   introduction, dual-stack devices may be affected and their access to
   IPv4 Internet, thus IPv4 service continuity, 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 recursive resolver needs to be
   dynamically provisioned on the IPv6-only host.

   DNS IPv6 address information is provided dynamically via DHCPv6,
   stateless autoconfiguration or in band signaling to all IPv6-ready
   hosts in the same way.  As the result both IPv6-only and dual-stack
   host are likely to use 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.




Kaliwoda & Binet          Expires April 8, 2013                 [Page 3]


Internet-Draft    Dual-stack and IPv6-only coexistence      October 2012


   IPv4-only host behavior:

   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 with IPv4 server from its IPv4 stack.

   o  With a DNS64 capable 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 synthesized AAAA record rather than A record
      only.  As the consequence, according to [RFC6724] the host may
      initiate the session from its IPv6 stack and such session will be
      forwarded via NAT64 translation device.

   IPv6-only host behavior:

   o  With a normal DNS server, IPv6-only host sends an AAAA query to
      DNS server using IPv6 transport.  Host will 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 synthesized
      AAAA response based on the A record DNS64 received from the
      authoritative server.  IPv6 session will be established through
      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 syntesized
      AAAA response.

   In summary, the dual-stack host name resolution result can be



Kaliwoda & Binet          Expires April 8, 2013                 [Page 4]


Internet-Draft    Dual-stack and IPv6-only coexistence      October 2012


   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 [RFC6724] is impacted and
   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 or
   not via NAT44 engine; but it will rather take IPv6/IPv4 translated
   path originated from its IPv6 stack.


5.  Impacted Service Provider networks

   There are multiple transitions strategies to achieve IPv6-only end-
   to-end connectivity.  Service Providers may decide for the phased
   approach i.e.

   o  first enable dual stack service for hosts

   o  followed by the IPv6-only support where IPv4 service continuity is
      satisfied via DNS64/NAT64

   o  with the last step of disabling IPv4 entirely.

   In case of cable/wireline networks dual stack service for home
   network behind managed bridge or router CPE is likely to be mandatory
   first phase.  It is possible that Service Provider managed home
   router will be IPv6-only on the access network side but it is
   orthogonal to the discussion in this draft as the home network will
   have to remain IPv4-enabled in order to provide IPv4 service
   continuity without the requirement for the unmanaged consumer devices
   to support IPv6 stack.  As the consequence, IPv6-only support via
   DNS64/NAT64 service will likely extend the dual IP stack connectivity
   service, rather than replacing it.

   In case of 3GPP networks, as stated in [RFC6459], dual stack is
   considered the preferred first phase of transition to IPv6.

   o  In pre-release-8 3GPP network with dual IPv4 and IPv6 PDP
      contexts.

   o  In release-8 and post-release-8 3GPP network with unique IPv4v6
      PDP context.

   In both scenarios, mobile device as well as other hosts when
   tethering is enabled as the managed service, will have native IPv4
   and IPv6 connectivity.  The IPv6-only connectivity support with
   DNS64/NAT64 is generally considered as the second stage in the IPv6
   transition strategy.




Kaliwoda & Binet          Expires April 8, 2013                 [Page 5]


Internet-Draft    Dual-stack and IPv6-only coexistence      October 2012


   There are two options for the cellular host to acquire only IPv6
   prefix information

   o  request an IPv4v6 PDP context and at the same time receive
      information that IPv4 address must not be requested for IPv4 PDP
      context to be configured.  As the result cellular host will
      receive only IPv6 prefix according to the configuration in HLR/HSS
      or in GGSN.

   o  request IPv6 PDP context

   In both cases DNS64/NAT64 solution must be deployed to ensure
   connectivity to IPv4 only applications when IPv6-only connectivity is
   provided by the service provider to cellular host.

   The former option is very similar to the cable/wireline network,
   where DNS64/NAT64 is an additional service on top of legacy IPv4 and
   IPv6 connectivity as two connectivity types (Dual Stack and IPv6
   only) will be deployed at the same time.  Additionally, since
   tethering as well as CPE connected to mobile infrastructures are more
   commonly used, the same issues than those depicted for fixed access
   are likely to happen in mobile infrastructure.

   The latter option is quite specific to the mobile context where some
   cellular hosts are configured with IPv6-only connectivity while
   others are configured with dual IP stack connectivity.  In such case,
   an option could be to deploy specific DNS servers for each type of
   hosts (with IPv6-only connectivity and dual stack connectivity) but
   it makes the network architecture more complex.

   This is not the intent of this draft to analyze the benefits of
   different transitions to IPv6 in the Service Provider networks or
   specifically to rule out skipping dual stack phase as the feasible
   approach.  As long as the Service Provider decides for the phased
   approach, with dual stack connectivity first, extended or replaced
   with IPv6-only support, then the impact analysis below is applicable.


6.  Impact analysis

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

   There are few reasons why:

   o  The goal is to make possible for IPv6-only devices to get access
      to IPv4 Internet and not to disrupt or alter the existing IPv4



Kaliwoda & Binet          Expires April 8, 2013                 [Page 6]


Internet-Draft    Dual-stack and IPv6-only coexistence      October 2012


      service

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

   o  IPv4 addresses exhaustion 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 device.  It may
      impact the session, degrade quality of experience for the
      customer.  It may also impact the logging requirements and volume
      of data conserved by the Service Provider.

   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 IPv4 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
      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)



Kaliwoda & Binet          Expires April 8, 2013                 [Page 7]


Internet-Draft    Dual-stack and IPv6-only coexistence      October 2012


      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.  IPv6 introduction with IPv4 service
   continuity solutions will increase CAPEX and OPEX.

   In case of mobile network some cellular hosts may have dual IP stack
   connectivity while other cellular hosts may have IPv6-only
   connectivity.  Following such assumption:

   o  Mobile SP strategy does not only depends on mobile hosts renewal
      as such some mean has to be found to modify remotely APN settings
      in mobile terminals

   o  Alternatively, in order to avoid impacts on hosts when supporting
      multiple PDP contexts, mobile SP may need to control PDP selection
      using HLR/HSS policy or/and GGSN/PDN-GW configuration.

   o  DNS server's IPv6 address provisioned via in band signaling for
      IPv6-only host and dual IP stack host will likely be different.
      While the host issues, as explained in this draft, are limited,
      Service Provider's operational complexity and costs is affected
      since new DNS servers need to be maintained.

   The goal of this document is agree on the problem statement, its
   impact and the following effort to find the solutions that will allow
   introducing IPv6/IPv4 translation service to IPv6-only hosts while
   keeping dual-stack hosts unaffected and IPv4 service unchanged.


7.  Security Considerations

   This document does not yet discuss security-related issues.


8.  Acknowledgements

   TODO


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



Kaliwoda & Binet          Expires April 8, 2013                 [Page 8]


Internet-Draft    Dual-stack and IPv6-only coexistence      October 2012


              (work in progress), February 2011.

   [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
              Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, January 2012.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.


Authors' Addresses

   Arkadiusz Kaliwoda
   Cisco Systems, Inc.
   Domaniewska 39b
   Warsaw  02-672
   Poland

   Email: akaliwod@cisco.com


   David Binet
   France Telecom Orange
   4 rue du Clos Courtel
   Cesson Sevigne  35512
   France

   Email: david.binet@orange.com





















Kaliwoda & Binet          Expires April 8, 2013                 [Page 9]


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