idnits 2.17.1 draft-ietf-v6ops-464xlat-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 8, 2012) is 4342 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6144' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC6459' is defined on line 602, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6144 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-02) exists of draft-hazeyama-widecamp-ipv6-only-experience-01 == Outdated reference: A later version (-17) exists of draft-ietf-behave-nat64-discovery-heuristic-07 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Mawatari 3 Internet-Draft Japan Internet Exchange Co.,Ltd. 4 Intended status: BCP M. Kawashima 5 Expires: November 9, 2012 NEC AccessTechnica, Ltd. 6 C. Byrne 7 T-Mobile USA 8 May 8, 2012 10 464XLAT: Combination of Stateful and Stateless Translation 11 draft-ietf-v6ops-464xlat-03 13 Abstract 15 This document describes an architecture (464XLAT) for providing 16 limited IPv4 connectivity across an IPv6-only network by combining 17 existing and well-known stateful protocol translation RFC 6146 in the 18 core and stateless protocol translation RFC 6145 at the edge. 464XLAT 19 is a simple and scalable technique to quickly deploy limited IPv4 20 access service to mobile and wireline IPv6-only edge networks without 21 encapsulation. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 9, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Motivation and Uniqueness of 464XLAT . . . . . . . . . . . . . 4 61 5. Network Architecture . . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Wireline Network Architecture . . . . . . . . . . . . . . 6 63 5.2. Wireless 3GPP Network Architecture . . . . . . . . . . . . 7 64 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Wireline Network Applicability . . . . . . . . . . . . . . 7 66 6.2. Wireless 3GPP Network Applicability . . . . . . . . . . . 8 67 7. Implementation Considerations . . . . . . . . . . . . . . . . 9 68 7.1. IPv6 Address Format . . . . . . . . . . . . . . . . . . . 9 69 7.2. IPv4/IPv6 Address Translation Chart . . . . . . . . . . . 9 70 7.3. Traffic Treatment Scenarios . . . . . . . . . . . . . . . 10 71 7.4. DNS Proxy Implementation . . . . . . . . . . . . . . . . . 11 72 7.5. IPv6 Prefix Handling . . . . . . . . . . . . . . . . . . . 11 73 7.6. Relationship between CLAT and NAT44 . . . . . . . . . . . 11 74 7.7. CLAT in a Gateway . . . . . . . . . . . . . . . . . . . . 11 75 7.8. CLAT to CLAT communications . . . . . . . . . . . . . . . 12 76 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 The IANA unallocated IPv4 address pool was exhausted on February 3, 88 2011. Each RIR's unallocated IPv4 address pool will exhaust in the 89 near future. It will be difficult for many networks to assign IPv4 90 addresses to end users, despite substantial IP connectivity growth 91 required for mobile devices, smart-grid, and cloud nodes. 93 This document describes an IPv4 over IPv6 solution as one of the 94 techniques for IPv4 service extension and encouragement of IPv6 95 deployment. 464XLAT is not a one for one replacement of full IPv4 96 functionality. The 464XLAT IPv4 service is limited to application 97 that function in a client server model and is not fit for IPv4 peer- 98 to-peer communication or inbound IPv4 connections. 100 The 464XLAT architecture described in this document uses IPv4/IPv6 101 translation standardized in [RFC6145] and [RFC6146]. It does not 102 require DNS64 [RFC6147] since a host may simply send IPv4 packets, 103 including packets to an IPv4 DNS server, which will be translated on 104 the CLAT to IPv6 and back to IPv4 on the PLAT. 464XLAT networks may 105 use DNS64 to enable single stateful translation [RFC6146] instead of 106 464XLAT double translation where possible. It is also possible to 107 provide single IPv4/IPv6 translation service, which will be needed in 108 the future case of IPv6-only servers and peers to be reached from 109 legacy IPv4-only hosts. The 464XLAT architecture encourages IPv6 110 transition by making IPv4 services reachable across IPv6-only 111 networks and providing IPv6 and IPv4 connectivity to single-stack 112 IPv4 or IPv6 servers and peers. 114 Running a single-stack IPv6-only network has several operational 115 benefits in terms of increasing scalability and decreasing 116 operational complexity. Unfortunately, there are important cases 117 where IPv6-only networks fail to meet subscriber expectations, as 118 described in [RFC6586]. The 464XLAT overcomes the issues described 119 in [RFC6586] to provide subscribers the full IPv6 and limited IPv4 120 functionality while providing the network operator the benefits of a 121 simple yet highly scalable single-stack IPv6 network. 123 2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Terminology 131 PLAT: PLAT is Provider side translator(XLAT) that complies with 132 [RFC6146]. It translates N:1 global IPv6 packets to global 133 IPv4 packets, and vice versa. 135 CLAT: CLAT is Customer side translator(XLAT) that complies with 136 [RFC6145]. It algorithmically translates 1:1 private IPv4 137 packets to global IPv6 packets, and vice versa. The CLAT 138 function is applicable to a router or an end-node such as a 139 mobile phone. CLAT SHOULD perform router function to 140 facilitate packets forwarding through the stateless 141 translation even if it is an end-node. In addition to 142 stateless translation, the CLAT as a common home router or 3G 143 router is expected to perform gateway functions such as DHCP 144 server and DNS proxy for local clients. 146 UE: The 3GPP term for user equipment. The most common type of UE 147 is a mobile phone. 149 PDP: A Packet Data Protocol (PDP) Context is the equivalent of a 150 virtual connection between the host and a gateway. 152 4. Motivation and Uniqueness of 464XLAT 154 1. Minimal IPv4 resource requirements, maximum IPv4 efficiency 156 464XLAT has low barriers to entry since only a small amount of 157 IPv4 addresses are needed to support the stateful translation 158 [RFC6146] function in the PLAT. With port-overloading, one IPv4 159 address can support millions of simultaneous translations. 161 Given that network operators are deploying IPv6-only access 162 networks because IPv4 resources are scarce, solutions that 163 require dual-stack (no IPv4 multiplexing) or stateless address 164 sharing (bounded static address multiplexing) are simply not 165 IPv4-efficient enough to solve the two-pronged challenge of 166 increasing IPv4 address scarcity and continued exponential 167 network edge growth for network operators. 169 2. No new protocols required, quick deployment 171 464XLAT can be deployed today, it uses existing RFCs ([RFC6145] 172 and [RFC6146]), and there exists implementations for both 173 wireline networks (CLAT in the home router) and wireless 3GPP 174 networks (CLAT in the UE). The ability to quickly deploy 464XLAT 175 is a critical feature given the urgency of IPv4 exhaustion and 176 brisk pace of internet growth. 178 3. Cost-effective transition to IPv6 180 When combined with DNS64 [RFC6147], the 464XLAT architecture only 181 requires double translation in the case of IPv4-referrals or 182 IPv4-only socket calls. Consequently, the network traffic in the 183 ISP backbone network is predominately IPv6 end-to-end or single 184 translation. This is especially cost-effective in wireless 3GPP 185 GSM and UMTS networks that would otherwise require two separate 186 PDP connections to support IPv4 and IPv6. 188 While translation on the CLAT is not always used, the CLAT 189 function is crucial for enabling the IPv4-only applications. All 190 IPv6-native flows pass end-to-end without any translation. This 191 is a beneficial solution for end-users, content providers, and 192 network operators that scale best with end-to-end IPv6 193 communication. 195 In summary, the 464XLAT architecture works today for service 196 providers that require large-scale strategic IPv6 deployments to 197 overcome the challenges of IPv4 address scarcity. Since 464XLAT is 198 stateful, there is no tight coupling or IPv4 address coordination 199 between the PLAT and the CLAT. Unlike other transition architectures 200 associated with tunneling or 201 [I-D.mdt-softwire-mapping-address-and-port], 464XLAT assumes that 202 IPv4 is scarce and IPv6 must work with today's existing systems as 203 much as possible. In the case of tunneling, the tunneling solutions 204 like Dual-Stack Lite [RFC6333] are known to break existing network 205 based deep packet inspection solutions like 3GPP standardized Policy 206 and Charging Control (PCC). 464XLAT does not require much IPv4 207 address space to enable the stateful translation [RFC6146] function 208 in the PLAT while providing global IPv4 and IPv6 reachability to 209 IPv6-only wireline and wireless subscribers. 211 5. Network Architecture 213 464XLAT architecture is shown in the following figure. 215 5.1. Wireline Network Architecture 217 ---- 218 | v6 | 219 ---- 220 | 221 ---- | .---+---. .------. 222 | v6 |-----+ / \ / \ 223 ---- | ------ / IPv6 \ ------ / IPv4 \ 224 +---| CLAT |---+ Internet +---| PLAT |---+ Internet | 225 ------- | ------ \ / ------ \ / 226 |v4p/v6 |--+ `---------' `----+----' 227 ------- | | 228 ----- | ----- 229 | v4p |----+ | v4g | 230 ----- | ----- 232 <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> 234 v6 : Global IPv6 235 v4p : Private IPv4 236 v4g : Global IPv4 238 Figure 1: Wireline Network Topology 240 5.2. Wireless 3GPP Network Architecture 242 ---- 243 | v6 | 244 ---- 245 | 246 .---+---. 247 / \ 248 / IPv6 \ 249 | Internet | 250 \ / 251 UE / Mobile Phone `---------' 252 +----------------------+ | 253 | ---- | | .---+---. .------. 254 | | v6 |----+ | / \ / \ 255 | ---- | ------| / IPv6 PDP \ ------ / IPv4 \ 256 | +---| CLAT |---+ Mobile Core +---| PLAT |--+ Internet | 257 | | ------| \ GGSN / ------ \ / 258 | | | \ ' `----+---' 259 | ------ | | `-------' | 260 | | v4p |---+ | ----- 261 | ------ | | | v4g | 262 +----------------------+ ----- 264 <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> 266 v6 : Global IPv6 267 v4p : Private IPv4 268 v4g : Global IPv4 270 Figure 2: Wireless 3GPP Network Topology 272 6. Applicability 274 6.1. Wireline Network Applicability 276 When an ISP has IPv6 access network infrastructure and 464XLAT, the 277 ISP can provide IPv4 service to end users across an IPv6 access 278 network. The result is that edge network growth is no longer tightly 279 coupled to the availability of scarce IPv4 addresses. 281 If the IXP or another provider operates the PLAT, the ISP is only 282 required to deploy an IPv6 access network. All ISPs do not need IPv4 283 access networks. They can migrate their access network to a simple 284 and highly scalable IPv6-only environment. Incidentally, Japan 285 Internet Exchange(JPIX) is providing 464XLAT trial service since July 286 2010. In addition to this, the effectiveness of 464XLAT was 287 confirmed in the WIDE camp Spring 2012. The result is described in 288 [I-D.hazeyama-widecamp-ipv6-only-experience]. 290 6.2. Wireless 3GPP Network Applicability 292 The vast majority of mobile wireless networks are compliant to Pre- 293 Release 9 3GPP standards. In Pre-Release 9 3GPP networks, GSM and 294 UMTS networks must signal and support both IPv4 and IPv6 PDP 295 attachments to access IPv4 and IPv6 network destinations. Since 296 there are 2 PDPs required to support 2 address families, this is 297 double the number of PDPs required to support the status quo of 1 298 address family, which is IPv4. Doubling the PDP count to support 299 IPv4 and IPv6 is generally not operationally viable since a large 300 portion of the network cost is derived from the number of PDP 301 attachments, both in terms of licenses from the network hardware 302 vendors and in terms of actual hardware resources required to support 303 and maintain the PDP signaling and mobility events. Doubling the 304 number of PDP attachments has been one of the major barriers to 305 introducing IPv6 in mobile networks. Dual-stack IPv4 and IPv6 simply 306 costs more from the network provider perspective and does not result 307 in any new revenues. In 3GPP Release 9 and forward, 2 PDPs are no 308 longer required but the scarcity of IPv4 addresses remain. 310 Now that both global and private IPv4 addresses are scarce to the 311 extent that it is a substantial business risk and limiting growth in 312 many areas, the mobile network providers must support IPv6 to solve 313 the IP address scarcity issue. It is not feasible to simply turn on 314 additional IPv6 PDP network attachments since that does not solve the 315 near-term IPv4 scarcity issues and it increases cost in most cases. 316 The most logical path forward is to replace IPv4 with IPv6 and 317 replace the common NAT44 with stateful translation [RFC6146] and 318 DNS64 [RFC6147]. Extensive live network testing with hundreds of 319 friendly-users has shown that IPv6-only network attachments for 320 mobile devices supports over 85% of the common applications on the 321 Android mobile operating systems. The remaining 15% of applications 322 do not work because the application requires an IPv4 socket or the 323 application does an IPv4-referral. These findings are consistent 324 with the mobile IPv6-only user experience in [RFC6586]. 326 464XLAT in combination with stateful translation [RFC6146] and DNS64 327 [RFC6147] allows 85% of the Android applications to continue to work 328 with single translation or native IPv6 access. For the remaining 15% 329 of applications that require IPv4 connectivity, the CLAT function on 330 the UE provides a private IPv4 address and IPv4 default-route on the 331 host for the applications to reference and bind to. Connections 332 sourced from the IPv4 interface are immediately routed to the CLAT 333 function and passed to the IPv6-only mobile network, destine to the 334 PLAT. In summary, the UE has the CLAT function that does a stateless 335 translation [RFC6145], but only when required. The mobile network 336 has a PLAT that does stateful translation [RFC6146]. 338 7. Implementation Considerations 340 7.1. IPv6 Address Format 342 IPv6 address format in 464XLAT is defined in Section 2.2 of 343 [RFC6052]. 345 7.2. IPv4/IPv6 Address Translation Chart 347 IPv4/IPv6 address translation chart is shown in the following figure. 349 Source IPv4 address 350 +----------------------------+ 351 | Global IPv4 address | 352 | assigned to IPv4 pool@PLAT | 353 +--------+ +----------------------------+ 354 | IPv4 | Destination IPv4 address 355 | server | +----------------------------+ 356 +--------+ | Global IPv4 address | 357 ^ | assigned to IPv4 server | 358 | +----------------------------+ 359 +--------+ 360 | PLAT | Stateful XLATE(IPv4:IPv6=1:n) 361 +--------+ 362 ^ 363 | 364 Source IPv6 address (IPv6 cloud) 365 +--------------------------------------------------------------+ 366 | IPv4-Embedded IPv6 address | 367 | defined in Section 2.2 of RFC6052 | 368 +--------------------------------------------------------------+ 369 Destination IPv6 address 370 +--------------------------------------------------------------+ 371 | IPv4-Embedded IPv6 address | 372 | defined in Section 2.2 of RFC6052 | 373 +--------------------------------------------------------------+ 374 (IPv6 cloud) 375 ^ 376 | 377 | 378 | 380 +--------+ 381 | | Case 1: CLAT will have a 382 | | dedicated IPv6 prefix 383 | | -> Stateless XLATE 384 | | (IPv4:IPv6=1:1) 385 | CLAT | 386 | | Case 2: CLAT will not have a 387 | | dedicated IPv6 prefix 388 | | -> NAT44 -> Stateless XLATE 389 | | (IPv4:IPv6=1:1) 390 +--------+ 391 ^ Source IPv4 address 392 | +----------------------------+ 393 +--------+ | Private IPv4 address | 394 | IPv4 | | assigned to IPv4 client | 395 | client | +----------------------------+ 396 +--------+ Destination IPv4 address 397 +----------------------------+ 398 | Global IPv4 address | 399 | assigned to IPv4 server | 400 +----------------------------+ 402 IPv4/IPv6 Address Translation Chart 404 7.3. Traffic Treatment Scenarios 406 +--------+-------------+-----------------------+-------------+ 407 | Server | Application | Traffic Treatment | Location of | 408 | | and Host | | Translation | 409 +--------+-------------+-----------------------+-------------+ 410 | IPv6 | IPv6 | End-to-end IPv6 | None | 411 +--------+-------------+-----------------------+-------------+ 412 | IPv4 | IPv6 | Stateful Translation | PLAT | 413 +--------+-------------+-----------------------+-------------+ 414 | IPv4 | IPv4 | 464XLAT | PLAT/CLAT | 415 +--------+-------------+-----------------------+-------------+ 416 | IPv6 | IPv4 | Stateless Translation | CLAT | 417 +--------+-------------+-----------------------+-------------+ 419 Traffic Treatment Scenarios 421 The above chart shows most common traffic types and traffic 422 treatment. 424 7.4. DNS Proxy Implementation 426 The CLAT SHOULD implement a DNS proxy as defined in [RFC5625]. The 427 case of an IPv4-only node behind CLAT querying an IPv4 DNS server is 428 undesirable since it requires both stateful and stateless translation 429 for each DNS lookup. The CLAT SHOULD set itself as the DNS server 430 via DHCP or other means and proxy DNS queries for IPv4 and IPv6 431 clients. Using the CLAT enabled home router or UE as a DNS proxy is 432 a normal consume gateway function and simplifies the traffic flow so 433 that only IPv6 native queries are made across the access network. 434 The CLAT SHOULD allow for a client to query any DNS server of its 435 choice and bypass the proxy. 437 7.5. IPv6 Prefix Handling 439 From the delegated DHCPv6 [RFC3633] prefix, a /64 is dedicated to 440 source and receive IPv6 packets associated with the stateless 441 translation [RFC6145]. 443 In another cases where the access network does not allow for a 444 dedicated translation prefix, the CLAT will do NAT44 such that all 445 private IPv4 sourced LAN packets appears from one private IPv4 446 address which is statelessly translated to one IPv6 address. 448 The CLAT MAY discover the Pref64::/n of the PLAT via some method such 449 as DHCPv6 option, TR-069, DNS APL RR [RFC3123] or 450 [I-D.ietf-behave-nat64-discovery-heuristic]. 452 7.6. Relationship between CLAT and NAT44 454 If the CLAT does not have dedicated IPv6 prefix for translation, the 455 CLAT does NAT44 as an internal function which never appears on the 456 wire. 458 Incoming source IPv4 packets from the LAN of [RFC1918] addresses are 459 NAT44 to the CLAT host address on the LAN of one [RFC1918] address. 460 Then, the CLAT will do a stateless translation [RFC6145] so that the 461 IPv4 packets from one [RFC1918] address are translated to the CLAT 462 LAN IPv6 address as described in [RFC6052]. 464 7.7. CLAT in a Gateway 466 The CLAT is a stateless translation feature which can be implemented 467 in a common home router or mobile phone that has a mobile router 468 feature. The router with CLAT function SHOULD provide common router 469 services such as DHCP of [RFC1918] addresses, DHCPv6, and DNS 470 service. The router SHOULD set itself as the DNS server advertised 471 via DHCP or other means to the clients so that it may implement the 472 DNS proxy function to avoid double translation of DNS request. 474 7.8. CLAT to CLAT communications 476 While CLAT to CLAT IPv4 communication may work when the client IPv4 477 subnets do not overlap, this traffic flow is out of scope. 464XLAT is 478 a hub and spoke architecture focused on enabling IPv4-only services 479 over IPv6-only access networks. 481 8. Deployment Considerations 483 Even if the Internet access provider for consumers is different from 484 the PLAT provider (another Internet access provider or Internet 485 exchange provider, etc.), it can implement traffic engineering 486 independently from the PLAT provider. Detailed reasons are below: 488 1. The Internet access provider for consumers can figure out IPv4 489 source address and IPv4 destination address from translated IPv6 490 packet header, so it can implement traffic engineering based on 491 IPv4 source address and IPv4 destination address (e.g. traffic 492 monitoring for each IPv4 destination address, packet filtering 493 for each IPv4 destination address, etc.). The tunneling methods 494 do not have such a advantage, without any deep packet inspection 495 for processing the inner IPv4 packet of the tunnel packet. 497 2. If the Internet access provider for consumers can assign IPv6 498 prefix greater than /64 for each subscriber, this 464XLAT 499 architecture can separate IPv6 prefix for native IPv6 packets and 500 XLAT prefix for IPv4/IPv6 translation packets. Accordingly, it 501 can identify the type of packets ("native IPv6 packets" and 502 "IPv4/IPv6 translation packets"), and implement traffic 503 engineering based on IPv6 prefix. 505 This 464XLAT architecture has two capabilities. One is a IPv4 -> 506 IPv6 -> IPv4 translation for sharing global IPv4 addresses, another 507 is a IPv4 -> IPv6 translation for reaching IPv6-only servers from 508 IPv4-only clients that can not support IPv6. IPv4-only clients must 509 be support through the long period of global transition to IPv6. 511 9. Security Considerations 513 To implement a PLAT, see security considerations presented in Section 514 5 of [RFC6146]. 516 To implement a CLAT, see security considerations presented in Section 517 7 of [RFC6145]. The CLAT MAY comply with [RFC6092]. 519 10. IANA Considerations 521 This document has no actions for IANA. 523 11. Acknowledgements 525 The authors would like to thank JPIX NOC members, JPIX 464XLAT trial 526 service members, Seiichi Kawamura, Dan Drown, Brian Carpenter, Rajiv 527 Asati, Washam Fan, Behcet Sarikaya, Jan Zorz, Remi Despres, Tatsuya 528 Oishi, Lorenzo Colitti, Erik Kline, Ole Troan, Maoke Chen, and Gang 529 Chen for their helpful comments. We also would like to thank Fred 530 Baker and Joel Jaeggli for their support. 532 12. References 534 12.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 540 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 541 October 2010. 543 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 544 IPv4/IPv6 Translation", RFC 6144, April 2011. 546 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 547 Algorithm", RFC 6145, April 2011. 549 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 550 NAT64: Network Address and Protocol Translation from IPv6 551 Clients to IPv4 Servers", RFC 6146, April 2011. 553 12.2. Informative References 555 [I-D.hazeyama-widecamp-ipv6-only-experience] 556 Hazeyama, H., Hiromi, R., Ishihara, T., and O. Nakamura, 557 "Experiences from IPv6-Only Networks with Transition 558 Technologies in the WIDE Camp Spring 2012", 559 draft-hazeyama-widecamp-ipv6-only-experience-01 (work in 560 progress), March 2012. 562 [I-D.ietf-behave-nat64-discovery-heuristic] 563 Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 564 IPv6 Prefix Used for IPv6 Address Synthesis", 565 draft-ietf-behave-nat64-discovery-heuristic-07 (work in 566 progress), March 2012. 568 [I-D.mdt-softwire-mapping-address-and-port] 569 Bao, C., Troan, O., Matsushima, S., Murakami, T., and X. 570 Li, "Mapping of Address and Port (MAP)", 571 draft-mdt-softwire-mapping-address-and-port-03 (work in 572 progress), January 2012. 574 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 575 E. Lear, "Address Allocation for Private Internets", 576 BCP 5, RFC 1918, February 1996. 578 [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes 579 (APL RR)", RFC 3123, June 2001. 581 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 582 Host Configuration Protocol (DHCP) version 6", RFC 3633, 583 December 2003. 585 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 586 BCP 152, RFC 5625, August 2009. 588 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 589 Customer Premises Equipment (CPE) for Providing 590 Residential IPv6 Internet Service", RFC 6092, 591 January 2011. 593 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 594 Beijnum, "DNS64: DNS Extensions for Network Address 595 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 596 April 2011. 598 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 599 Stack Lite Broadband Deployments Following IPv4 600 Exhaustion", RFC 6333, August 2011. 602 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 603 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 604 Partnership Project (3GPP) Evolved Packet System (EPS)", 605 RFC 6459, January 2012. 607 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 608 Network", RFC 6586, April 2012. 610 Authors' Addresses 612 Masataka Mawatari 613 Japan Internet Exchange Co.,Ltd. 614 KDDI Otemachi Building 19F, 1-8-1 Otemachi, 615 Chiyoda-ku, Tokyo 100-0004 616 JAPAN 618 Phone: +81 3 3243 9579 619 Email: mawatari@jpix.ad.jp 621 Masanobu Kawashima 622 NEC AccessTechnica, Ltd. 623 800, Shimomata 624 Kakegawa-shi, Shizuoka 436-8501 625 JAPAN 627 Phone: +81 537 23 9655 628 Email: kawashimam@vx.jp.nec.com 630 Cameron Byrne 631 T-Mobile USA 632 Bellevue, Washington 98006 633 USA 635 Email: cameron.byrne@t-mobile.com