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]