idnits 2.17.1 draft-kaliwoda-sunset4-dual-ipv6-coexist-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2012) is 4214 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SUNSET4 A. Kaliwoda 3 Internet-Draft Cisco 4 Intended status: Informational D. Binet 5 Expires: April 8, 2013 France Telecom Orange 6 October 5, 2012 8 Co-existence of both dual-stack and IPv6-only hosts 9 draft-kaliwoda-sunset4-dual-ipv6-coexist-01 11 Abstract 13 Some networks are expected to support IPv4-only, dual-stack, and 14 IPv6-only hosts at the same time. Such networks may want to add 15 IPv6/IPv4 translation for the IPv6-only host so it can access servers 16 on the IPv4 Internet. Adding translation service to the IPv6-enabled 17 network may change dual-stack host behavior and affect the way 18 deployed network is working. This document defines the problem 19 statement for such networks. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 8, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. DNS64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Host behavior analysis . . . . . . . . . . . . . . . . . . . . 3 59 5. Impacted Service Provider networks . . . . . . . . . . . . . . 5 60 6. Impact analysis . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 Many networks are undergoing the transition to IPv6. Whatever 69 transition method is selected by the Service Provider, the main 70 challenge is to maintain IPv4 access service with minimized quality 71 of experience impact for the customers. It can be expected that 72 access to IPv4 only servers from IPv4-only hosts or dual-stack hosts 73 may be impacted by IPv4 addresses exhaust problem and IPv4 port 74 sharing solution. In case of IPv6-only hosts the Service Provider is 75 likely to provide IPv6/IPv4 translation service in order to maintain 76 IPv4 service continuity. 78 2. Problem Statement 80 Addition of IPv6/IPv4 translation service is for IPv6-only hosts to 81 allow them accessing IPv4-only servers. It may be assumed and 82 expected that IPv4-only and dual-stack hosts are not influenced by 83 the translation service and they access IPv4-only Internet resources 84 the same way as before without affecting the quality of experience of 85 the customer. 87 While it is true that for IPv4-only devices, IPv4-only Internet 88 resources access will not be impacted by DNS64/NAT64 service 89 introduction, dual-stack devices may be affected and their access to 90 IPv4 Internet, thus IPv4 service continuity, may be changed. 92 3. DNS64 94 IPv6-only host needs to perform DNS query to a DNS64 recursive 95 resolver in order to use IPv6/IPv4 translator and get access to IPv4- 96 only server. IPv6 address of DNS64 recursive resolver needs to be 97 dynamically provisioned on the IPv6-only host. 99 DNS IPv6 address information is provided dynamically via DHCPv6, 100 stateless autoconfiguration or in band signaling to all IPv6-ready 101 hosts in the same way. As the result both IPv6-only and dual-stack 102 host are likely to use the same IPv6 DNS address to resolve FQDN, 103 unless special measures are taken [I-D.wing-behave-dns64-config]. 105 4. Host behavior analysis 107 Let's assume that host initiates IP connection to the IPv4-only 108 server identified with FQDN, where FQDN has only A RR defined in the 109 DNS servers. 111 IPv4-only host behavior: 113 o With a normal DNS server, IPv4-only host sends an A query to DNS 114 server using IPv4 transport, resolves IPv4 address of the server 115 and initiates the session with IPv4 server from its IPv4 stack. 117 o With a DNS64 capable server, the behavior is exactly the same 118 since DNS64 extensions are not invoked for an A query. 120 Dual-stack host behavior: 122 o With a normal DNS server, dual-stack host sends query to DNS 123 server using either IPv4 or IPv6 transport. In either case it 124 sends both an A and an AAAA query. Since the assumption is that 125 FQDN being resolved has only A RR defined, host should always 126 resolve IPv4 address only of the server. It will initiate the 127 session from its IPv4 stack. 129 o With a DNS64 server, the response to a query is different since it 130 will include the synthesized AAAA record rather than A record 131 only. As the consequence, according to [RFC6724] the host may 132 initiate the session from its IPv6 stack and such session will be 133 forwarded via NAT64 translation device. 135 IPv6-only host behavior: 137 o With a normal DNS server, IPv6-only host sends an AAAA query to 138 DNS server using IPv6 transport. Host will not resolve the FQDN 139 of IPv4-only server since there is no AAAA RR defined. 141 o With a DNS64 server, IPv6-only host should receive synthesized 142 AAAA response based on the A record DNS64 received from the 143 authoritative server. IPv6 session will be established through 144 NAT64 translation device. 146 It is possible that Service Provider will add separate DNS server 147 specifically to run DNS64 extensions and leave another DNS server 148 unchanged. In such case, the name resolution outcome of the dual- 149 stack host may be dependant on which DNS server is being contacted. 151 o If dual-stack host sends request over IPv4 transport, the request 152 will be responded by normal DNS server with A record only. 154 o If dual-stack hosts sends request over IPv6 transport, the request 155 will be responded by DNS64 server and it will contain syntesized 156 AAAA response. 158 In summary, the dual-stack host name resolution result can be 159 affected by adding DNS64 service. As the consequence the way dual- 160 stack hosts communicates with IPv4-only server may be affected since 161 the source address selection according to [RFC6724] is impacted and 162 eventually dual-stack host may no longer take the IPv4 path i.e. will 163 not initiate the session from its IPv4 stack that may be forwarded or 164 not via NAT44 engine; but it will rather take IPv6/IPv4 translated 165 path originated from its IPv6 stack. 167 5. Impacted Service Provider networks 169 There are multiple transitions strategies to achieve IPv6-only end- 170 to-end connectivity. Service Providers may decide for the phased 171 approach i.e. 173 o first enable dual stack service for hosts 175 o followed by the IPv6-only support where IPv4 service continuity is 176 satisfied via DNS64/NAT64 178 o with the last step of disabling IPv4 entirely. 180 In case of cable/wireline networks dual stack service for home 181 network behind managed bridge or router CPE is likely to be mandatory 182 first phase. It is possible that Service Provider managed home 183 router will be IPv6-only on the access network side but it is 184 orthogonal to the discussion in this draft as the home network will 185 have to remain IPv4-enabled in order to provide IPv4 service 186 continuity without the requirement for the unmanaged consumer devices 187 to support IPv6 stack. As the consequence, IPv6-only support via 188 DNS64/NAT64 service will likely extend the dual IP stack connectivity 189 service, rather than replacing it. 191 In case of 3GPP networks, as stated in [RFC6459], dual stack is 192 considered the preferred first phase of transition to IPv6. 194 o In pre-release-8 3GPP network with dual IPv4 and IPv6 PDP 195 contexts. 197 o In release-8 and post-release-8 3GPP network with unique IPv4v6 198 PDP context. 200 In both scenarios, mobile device as well as other hosts when 201 tethering is enabled as the managed service, will have native IPv4 202 and IPv6 connectivity. The IPv6-only connectivity support with 203 DNS64/NAT64 is generally considered as the second stage in the IPv6 204 transition strategy. 206 There are two options for the cellular host to acquire only IPv6 207 prefix information 209 o request an IPv4v6 PDP context and at the same time receive 210 information that IPv4 address must not be requested for IPv4 PDP 211 context to be configured. As the result cellular host will 212 receive only IPv6 prefix according to the configuration in HLR/HSS 213 or in GGSN. 215 o request IPv6 PDP context 217 In both cases DNS64/NAT64 solution must be deployed to ensure 218 connectivity to IPv4 only applications when IPv6-only connectivity is 219 provided by the service provider to cellular host. 221 The former option is very similar to the cable/wireline network, 222 where DNS64/NAT64 is an additional service on top of legacy IPv4 and 223 IPv6 connectivity as two connectivity types (Dual Stack and IPv6 224 only) will be deployed at the same time. Additionally, since 225 tethering as well as CPE connected to mobile infrastructures are more 226 commonly used, the same issues than those depicted for fixed access 227 are likely to happen in mobile infrastructure. 229 The latter option is quite specific to the mobile context where some 230 cellular hosts are configured with IPv6-only connectivity while 231 others are configured with dual IP stack connectivity. In such case, 232 an option could be to deploy specific DNS servers for each type of 233 hosts (with IPv6-only connectivity and dual stack connectivity) but 234 it makes the network architecture more complex. 236 This is not the intent of this draft to analyze the benefits of 237 different transitions to IPv6 in the Service Provider networks or 238 specifically to rule out skipping dual stack phase as the feasible 239 approach. As long as the Service Provider decides for the phased 240 approach, with dual stack connectivity first, extended or replaced 241 with IPv6-only support, then the impact analysis below is applicable. 243 6. Impact analysis 245 The possible change of IPv4 forwarding path of dual-stack host can be 246 seen as the side effect of IPv6 introduction strategy and IPv6/IPv4 247 translation service requirement. It may be highly undesired. 249 There are few reasons why: 251 o The goal is to make possible for IPv6-only devices to get access 252 to IPv4 Internet and not to disrupt or alter the existing IPv4 253 service 255 o Service Provider does not control and does not know what IPv4 256 forwarding path is selected by dual-stack end devices. It 257 increases the operational complexity e.g. when solving 258 connectivity problem. 260 o IPv4 addresses exhaustion may not be a problem in the Service 261 Provider network. In such case outbound session to IPv4 servers 262 initiated by IPv4-ready host is not supposed to be NATed in the SP 263 network. In case dual-stack device initiates session via IPv6/ 264 IPv4 translator, the traffic passes stateful NAT64 device. It may 265 impact the session, degrade quality of experience for the 266 customer. It may also impact the logging requirements and volume 267 of data conserved by the Service Provider. 269 o IPv6/IPv4 translation (NAT64) may have different NAT 270 characteristics compared with deployed NAT44 solution e.g. 271 different ALG implemented. For example if NAT44 supports ALG that 272 NAT64 does not support, the communication of dual-stack device 273 with IPv4-only server may be dependant on which NAT engine it goes 274 through. Even in the case of FTP application, FTP64 ALG is not 275 exactly the same as FTP ALG. Thus switching the IPv4 path may 276 break some applications and may have operational impact. 278 o Troubleshooting of IPv4 connectivity, monitoring of NAT44 279 resources, operational procedures, technical support; needs to be 280 adjusted to handle the possible change of IPv4 forwarding path 281 through the SP network. 283 Another important consequence of providing DNS64 information to the 284 host is that if affects the scaling of the network design and may 285 lead to suboptimum (in terms of hardware resources and address usage) 286 and thus costly solution. This is based on the following reasoning: 288 o Stateful NAT engine is scaled for given peak traffic and has IPv4 289 public resource of X assigned. Traffic through the NAT engine 290 represents the bidirectional traffic with IPv4-only servers and it 291 says nothing about IP stack support of the host i.e. it can be 292 IPv4-only or dual-stack host. 294 o When DNS64 information is distributed, dual-stack device may take 295 either NAT44 path or IPv6/IPv4 translated path, depending on the 296 host behavior or the way DNS64 is enabled in the network. 298 o Since the IPv4 path selection is not fully deterministic from the 299 Service Provider perspective i.e. it may depend on the host 300 behavior; NAT44 engine reserved resources (HW, address pools) 301 should stay the same in case traffic from dual-stack hosts keeps 302 the same forwarding path. On the other hand stateful NAT64 should 303 be scaled not only for the traffic from IPv6-only hosts but should 304 be also ready to take some traffic from dual-stack hosts. 306 As such it can be expected that the resources for NAT44 and NAT64 307 will not be optimally used. IPv6 introduction with IPv4 service 308 continuity solutions will increase CAPEX and OPEX. 310 In case of mobile network some cellular hosts may have dual IP stack 311 connectivity while other cellular hosts may have IPv6-only 312 connectivity. Following such assumption: 314 o Mobile SP strategy does not only depends on mobile hosts renewal 315 as such some mean has to be found to modify remotely APN settings 316 in mobile terminals 318 o Alternatively, in order to avoid impacts on hosts when supporting 319 multiple PDP contexts, mobile SP may need to control PDP selection 320 using HLR/HSS policy or/and GGSN/PDN-GW configuration. 322 o DNS server's IPv6 address provisioned via in band signaling for 323 IPv6-only host and dual IP stack host will likely be different. 324 While the host issues, as explained in this draft, are limited, 325 Service Provider's operational complexity and costs is affected 326 since new DNS servers need to be maintained. 328 The goal of this document is agree on the problem statement, its 329 impact and the following effort to find the solutions that will allow 330 introducing IPv6/IPv4 translation service to IPv6-only hosts while 331 keeping dual-stack hosts unaffected and IPv4 service unchanged. 333 7. Security Considerations 335 This document does not yet discuss security-related issues. 337 8. Acknowledgements 339 TODO 341 9. Normative References 343 [I-D.wing-behave-dns64-config] 344 Wing, D., "IPv6-only and Dual Stack Hosts on the Same 345 Network with DNS64", draft-wing-behave-dns64-config-03 346 (work in progress), February 2011. 348 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 349 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 350 Partnership Project (3GPP) Evolved Packet System (EPS)", 351 RFC 6459, January 2012. 353 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 354 "Default Address Selection for Internet Protocol Version 6 355 (IPv6)", RFC 6724, September 2012. 357 Authors' Addresses 359 Arkadiusz Kaliwoda 360 Cisco Systems, Inc. 361 Domaniewska 39b 362 Warsaw 02-672 363 Poland 365 Email: akaliwod@cisco.com 367 David Binet 368 France Telecom Orange 369 4 rue du Clos Courtel 370 Cesson Sevigne 35512 371 France 373 Email: david.binet@orange.com