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]