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]