idnits 2.17.1 draft-mawatari-v6ops-464xlat-00.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 (January 15, 2012) is 4486 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6144' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-3gpp-eps' is defined on line 527, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-05) exists of draft-arkko-ipv6-only-experience-04 == Outdated reference: A later version (-17) exists of draft-ietf-behave-nat64-discovery-heuristic-04 == Outdated reference: A later version (-03) exists of draft-mdt-softwire-mapping-address-and-port-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: Informational M. Kawashima 5 Expires: July 18, 2012 NEC AccessTechnica, Ltd. 6 C. Byrne 7 T-Mobile USA 8 January 15, 2012 10 464XLAT: Combination of Stateful and Stateless Translation 11 draft-mawatari-v6ops-464xlat-00 13 Abstract 15 This document describes an architecture (464XLAT) for providing IPv4 16 connectivity across an IPv6-only network by combining existing and 17 well-known stateful protocol translation RFC 6146 and stateless 18 protocol translation RFC 6145. 464XLAT is a simple and scalable 19 technique to quickly deploy IPv4 access service to mobile and 20 wireline IPv6-only networks without encapsulation. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 18, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Motivation and Uniqueness of 464XLAT . . . . . . . . . . . . . 4 60 5. Network Architecture . . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Wireline Network Architecture . . . . . . . . . . . . . . 6 62 5.2. Wireless 3GPP Network Architecture . . . . . . . . . . . . 7 63 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1. Wireline Network Applicability . . . . . . . . . . . . . . 7 65 6.2. Wireless 3GPP Network Applicability . . . . . . . . . . . 8 66 7. Implementation Considerations . . . . . . . . . . . . . . . . 9 67 7.1. IPv6 Address Format . . . . . . . . . . . . . . . . . . . 9 68 7.2. IPv4/IPv6 Address Translation Chart . . . . . . . . . . . 10 69 7.3. Traffic Treatment Scenarios . . . . . . . . . . . . . . . 11 70 7.4. DNS Proxy Implementation . . . . . . . . . . . . . . . . . 11 71 7.5. IPv6 Prefix Handling . . . . . . . . . . . . . . . . . . . 11 72 7.6. IPv6 Fragment Header Consideration . . . . . . . . . . . . 11 73 7.7. Auto IPv6 Prefix Assignment . . . . . . . . . . . . . . . 11 74 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 12 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 The IANA unallocated IPv4 address pool was exhausted on February 3, 86 2011. Each RIR's unallocated IPv4 address pool will exhaust in the 87 near future. It will be difficult for many networks to assign IPv4 88 addresses to end users, despite substantial IP connectivity growth 89 required for mobile devices, smart-grid, and cloud nodes. 91 This document describes an IPv4 over IPv6 solution as one of the 92 techniques for IPv4 address extension and encouragement of IPv6 93 deployment. 95 The 464XLAT architecture described in this document uses IPv4/IPv6 96 translation standardized in [RFC6145] and [RFC6146]. It does not 97 require DNS64 [RFC6147], but it may use DNS64 to enable single 98 stateful translation [RFC6146] instead of 464XLAT double translation 99 where possible. It is also possible to provide single IPv4/IPv6 100 translation service, which will be needed in the future case of IPv6- 101 only servers and peers to be reached from legacy IPv4-only hosts. 102 The 464XLAT architecture encourages IPv6 transition by making IPv4 103 services reachable across IPv6-only networks and providing IPv6 and 104 IPv4 connectivity to single-stack IPv4 or IPv6 servers and peers. 106 Running a single-stack IPv6-only network has several operational 107 benefits in terms of increasing scalability and decreasing 108 operational complexity. Unfortunately, there are meaningful cases 109 where IPv6-only networks fail to meet subscriber expectations, as 110 described in [I-D.arkko-ipv6-only-experience]. The 464XLAT overcomes 111 the issues described in [I-D.arkko-ipv6-only-experience] to provide 112 subscribers the full dual-stack functionality while providing the 113 network operator the benefits of a simple yet highly scalable single- 114 stack IPv6 network. 116 2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 3. Terminology 124 PLAT: PLAT is Provider side translator(XLAT). A stateful 125 translator complies with [RFC6146] that performs 1:N 126 translation. It translates IPv6 address to global IPv4 127 address, and vice versa. 129 CLAT: CLAT is Customer side translator(XLAT). A stateless 130 translator complies with [RFC6145] that performs 1:1 131 translation. It algorithmically translates private IPv4 132 address to global IPv6 address, and vice versa. CLAT 133 function is applicable to a router, or end-node such as a 134 mobile phone. The presence of DNS64 [RFC6147] and any port 135 mapping algorithm are not required. 137 UE: The 3GPP term for user equipment. The most common type of UE 138 is a mobile phone. 140 PDP: A Packet Data Protocol (PDP) Context is the equivalent of a 141 virtual connection between the host and a gateway. 143 4. Motivation and Uniqueness of 464XLAT 145 1. Minimal IPv4 resource requirements 147 464XLAT is the most efficient use of scarce IPv4 addresses for 148 networks that have fast growing edges. The primary motivation 149 for deploying IPv6 is the exhaustion of IPv4 addresses and the 150 risk that exhaustion poses to future internet growth. 464XLAT 151 directly takes on the challenge of IPv4 address exhaustion by 152 providing efficient stateful IPv4 address sharing at the PLAT and 153 decoupling the edge network growth from the availability of 154 scarce IPv4 addresses. 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. 160 Given that network operators are deploying IPv6 because IPv4 161 resources are scarce, solutions that require dual-stack (no IPv4 162 multiplexing) or stateless address sharing (bounded static 163 address multiplexing) are simply not IPv4-efficient enough to 164 solve the two-pronged challenge of IPv4 address scarcity and 165 continued exponential network edge growth. 167 2. No new protocols required 169 464XLAT can be deployed today, it uses existing RFCs ([RFC6145] 170 and [RFC6146]), and there exists implementations for both 171 wireline network (in CLAT in the Home Gateway) and wireless 3GPP 172 network (in CLAT in the UE). The ability to quickly deploy 173 464XLAT is a critical feature given the urgency of IPv4 174 exhaustion and brisk pace of internet growth. 176 3. Cost-effective transition to IPv6 178 When combined with DNS64 [RFC6147], the 464XLAT architecture only 179 requires double translation in the case of IPv4-referrals or 180 IPv4-only socket calls. Consequently, the network traffic in the 181 ISP backbone network is predominately IPv6 end-to-end or single 182 translation. This is especially cost-effective in wireless 3GPP 183 network that would otherwise require two separate PDP connections 184 to support IPv4 and IPv6. 186 While translation on the CLAT is not always used, the CLAT 187 function is crucial for enabling the IPv4-only applications and 188 providing IP address family service parity to the end-users. All 189 IPv6-native flows pass end-to-end without any translation. This 190 is a beneficial solution for end-users, content providers, and 191 network operators that scale best with end-to-end IPv6 192 communication. 194 In summary, the 464XLAT architecture works today for service 195 providers that require large-scale strategic IPv6 deployments to 196 overcome the challenges of IPv4 address scarcity. Unlike other 197 transition architectures associated with tunneling or 198 [I-D.mdt-softwire-mapping-address-and-port], 464XLAT properly assumes 199 that IPv4 is scarce and IPv6 must work with today's existing systems 200 as much as possible. In the case of tunneling, the tunneling 201 solutions like Dual-Stack Lite [RFC6333] are known to break existing 202 network based deep packet inspection solutions like 3GPP standardized 203 Policy and Charging Control (PCC). 464XLAT does not require much IPv4 204 address space to enable stateful translation [RFC6146] function in 205 the PLAT while providing global IPv4 and IPv6 reachability to IPv6- 206 only wireline and wireless subscribers. 208 5. Network Architecture 210 464XLAT architecture is shown in the following figure. 212 5.1. Wireline Network Architecture 214 ---- 215 | v6 | 216 ---- 217 | 218 ---- | .---+---. .------. 219 | v6 |-----+ / \ / \ 220 ---- | ------ / IPv6 \ ------ / IPv4 \ 221 +---| CLAT |---+ Internet +---| PLAT |---+ Internet | 222 ------- | ------ \ / ------ \ / 223 |v4p/v6 |--+ `---------' `----+----' 224 ------- | | 225 ----- | ----- 226 | v4p |----+ | v4g | 227 ----- | ----- 229 <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> 231 v6 : Global IPv6 232 v4p : Private IPv4 233 v4g : Global IPv4 235 Figure 1: Wireline Network Topology 237 5.2. Wireless 3GPP Network Architecture 239 ---- 240 | v6 | 241 ---- 242 | 243 .---+---. 244 / \ 245 / IPv6 \ 246 | Internet | 247 \ / 248 UE / Mobile Phone `---------' 249 +----------------------+ | 250 | ---- | | .---+---. .------. 251 | | v6 |----+ | / \ / \ 252 | ---- | ------| / IPv6 PDP \ ------ / IPv4 \ 253 | +---| CLAT |---+ Mobile Core +---| PLAT |--+ Internet | 254 | | ------| \ GGSN / ------ \ / 255 | | | \ ' `----+---' 256 | ------ | | `-------' | 257 | | v4p |---+ | ----- 258 | ------ | | | v4g | 259 +----------------------+ ----- 261 <- v4p -> XLAT <--------- v6 --------> XLAT <- v4g -> 263 v6 : Global IPv6 264 v4p : Private IPv4 265 v4g : Global IPv4 267 Figure 2: Wireless 3GPP Network Topology 269 6. Applicability 271 6.1. Wireline Network Applicability 273 When an ISP has IPv6 access network infrastructure and 464XLAT, the 274 ISP can provide IPv4 service to end users across an IPv6 access 275 network. The result is that edge network growth is no longer tightly 276 coupled to the availability of scarce IPv4 addresses. 278 If the IXP or another provider operates the PLAT, the ISP is only 279 required to deploy an IPv6 access network. All ISPs do not need IPv4 280 access networks. They can migrate their access network to a simple 281 and highly scalable IPv6-only environment. Incidentally, Japan 282 Internet Exchange(JPIX) is providing 464XLAT trial service since July 283 2010. 285 6.2. Wireless 3GPP Network Applicability 287 The vast majority of mobile wireless networks are compliant to Pre- 288 Release 9 3GPP standards. In Pre-Release 9 3GPP networks, GSM and 289 UMTS networks must signal and support both IPv4 and IPv6 PDP 290 attachments to access IPv4 and IPv6 network destinations. Since 291 there are 2 PDPs required to support 2 address families, this is 292 double the number of PDPs required to support the status quo of 1 293 address family, which is IPv4. Doubling the PDP count to support 294 IPv4 and IPv6 is generally not operationally viable since a large 295 portion of the network cost is derived from the number of PDP 296 attachments, both in terms of licenses from the network hardware 297 vendors and in terms of actual hardware resources required to support 298 and maintain the PDP signaling and mobility events. Doubling the 299 number of PDP attachments has been one of the major barriers to 300 introducing IPv6 in mobile networks. Dual-stack IPv4 and IPv6 simply 301 costs more from the network provider perspective and does not result 302 in any new revenues. 304 Now that both global and private IPv4 addresses are scarce to the 305 extent that it is a substantial business risk and limiting growth in 306 many areas, the mobile network providers must support IPv6 to solve 307 the IP address scarcity issue. It is not feasible to simply turn on 308 additional IPv6 PDP network attachments since that does not solve the 309 near-term IPv4 scarcity issues and it increases cost. The most 310 logical path forward is to replace IPv4 with IPv6 and replace the 311 common NAT44 with stateful translation [RFC6146] and DNS64 [RFC6147]. 312 Extensive live network testing with hundreds of friendly-users has 313 shown that IPv6-only network attachments for mobile devices covers 314 over 90% of the common use-cases in Symbian and Android mobile 315 operating systems. The remaining 10% of use-cases do not work 316 because the application requires an IPv4 socket or the application 317 does an IPv4-referral. These findings are consistent with the mobile 318 IPv6-only user experience in [I-D.arkko-ipv6-only-experience]. 320 464XLAT in combination with stateful translation [RFC6146] and DNS64 321 [RFC6147] allows 90% of the applications to continue to work with 322 single translation. For the remaining 10% of applications that 323 require IPv4 connectivity, the CLAT function on the UE provides a 324 private IPv4 address and IPv4 default-route on the host for the 325 applications to reference and bind to. Connections sourced from the 326 IPv4 interface are immediately routed to the CLAT function and passed 327 to the IPv6-only mobile network, destine to the PLAT. In summary, 328 the UE has the CLAT function that does a stateless translation 329 [RFC6145], but only when required, and the mobile network has a PLAT 330 that does stateful translation [RFC6146]. 332 7. Implementation Considerations 334 7.1. IPv6 Address Format 336 IPv6 address format in 464XLAT is presented in the following format. 338 +-----------------------------------------------+---------------+ 339 | XLAT prefix(96) | IPv4(32) | 340 +-----------------------------------------------+---------------+ 342 IPv6 Address Format for 464XLAT 344 Source address and destination address have IPv4 address embedded in 345 the low-order 32 bits of the IPv6 address. The format is defined in 346 Section 2.2 of [RFC6052]. However, 464XLAT does not use the Well- 347 Known IPv6 Prefix "64:ff9b::/96". 349 7.2. IPv4/IPv6 Address Translation Chart 351 Source IPv4 address 352 +----------------------------+ 353 | Global IPv4 (32bit) | 354 | assigned to IPv4 pool@PLAT | 355 +--------+ +----------------------------+ 356 | IPv4 | Destination IPv4 address 357 | server | +----------------------------+ 358 +--------+ | Global IPv4 (32bit) | 359 ^ | assigned to IPv4 server | 360 | +----------------------------+ 361 +--------+ 362 | PLAT | Stateful XLATE(IPv4:IPv6=1:n) 363 +--------+ 364 ^ 365 | 366 Source IPv6 address (IPv6 cloud) 367 +--------------------------------------+----------------------------+ 368 | XLAT prefix for source (96bit) | Private IPv4 (32bit) | 369 | assigned to each consumer of ISP | assigned to IPv4 client | 370 +--------------------------------------+----------------------------+ 371 Destination IPv6 address 372 +--------------------------------------+----------------------------+ 373 | XLAT prefix for destination (96bit) | Global IPv4 (32bit) | 374 | assigned to PLAT | assigned to IPv4 server | 375 +--------------------------------------+----------------------------+ 376 (IPv6 cloud) 377 ^ 378 | 379 +--------+ 380 | CLAT | Stateless XLATE(IPv4:IPv6=1:1) 381 +--------+ 382 ^ Source IPv4 address 383 | +----------------------------+ 384 +--------+ | Private IPv4 (32bit) | 385 | IPv4 | | assigned to IPv4 client | 386 | client | +----------------------------+ 387 +--------+ Destination IPv4 address 388 +----------------------------+ 389 | Global IPv4 (32bit) | 390 | assigned to IPv4 server | 391 +----------------------------+ 393 IPv4/IPv6 Address Translation Chart 395 7.3. Traffic Treatment Scenarios 397 +--------+-------------+-----------------------+-------------+ 398 | Server | Application | Traffic Treatment | Location of | 399 | | and Host | | Translation | 400 +--------+-------------+-----------------------+-------------+ 401 | IPv6 | IPv6 | End-to-end IPv6 | None | 402 +--------+-------------+-----------------------+-------------+ 403 | IPv4 | IPv6 | Stateful Translation | PLAT | 404 +--------+-------------+-----------------------+-------------+ 405 | IPv4 | IPv4 | 464XLAT | PLAT/CLAT | 406 +--------+-------------+-----------------------+-------------+ 407 | IPv6 | IPv4 | Stateless Translation | CLAT | 408 +--------+-------------+-----------------------+-------------+ 410 Traffic Treatment Scenarios 412 The above chart shows most common traffic types and traffic 413 treatment. 415 7.4. DNS Proxy Implementation 417 If a router implement CLAT function, it performs DNS Proxy for IPv4 418 hosts and IPv6 hosts in end-user network. It MUST provide name 419 resolution with IPv6 transport. It does not need DNS64 [RFC6147] 420 function. 422 7.5. IPv6 Prefix Handling 424 If CLAT gets a single /64 prefix from WAN interface, it MUST perform 425 NDP for 464XLAT IPv6 addresses. 427 7.6. IPv6 Fragment Header Consideration 429 In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 430 Fragment Header, since IPv4 host does not set the DF bit. However, 431 the IPv6 Fragment Header has been shown to cause operational 432 difficulties in practice due to limited firewall fragmentation 433 support, etc. Therefore, the PLAT and CLAT may provide a 434 configuration function that allows the PLAT and CLAT not to include 435 the Fragment Header for the non-fragmented IPv6 packets. At any 436 rate, both behaviors SHOULD match. 438 7.7. Auto IPv6 Prefix Assignment 440 Source IPv6 prefix assignment in CLAT is via DHCPv6 prefix delegation 441 or another method. Destination IPv6 prefix assignment in CLAT is via 442 some method. (e.g., DHCPv6 option, TR-069, DNS, HTTP, 443 [I-D.ietf-behave-nat64-discovery-heuristic], etc.) 445 8. Deployment Considerations 447 Even if the Internet access provider for consumers is different from 448 the PLAT provider (another Internet access provider or Internet 449 exchange provider, etc.), it can implement traffic engineering 450 independently from the PLAT provider. Detailed reasons are below: 452 1. The Internet access provider for consumers can figure out IPv4 453 source address and IPv4 destination address from translated IPv6 454 packet header, so it can implement traffic engineering based on 455 IPv4 source address and IPv4 destination address (e.g. traffic 456 monitoring for each IPv4 destination address, packet filtering 457 for each IPv4 destination address, etc.). The tunneling methods 458 do not have such a advantage, without any deep packet inspection 459 for processing the inner IPv4 packet of the tunnel packet. 461 2. If the Internet access provider for consumers can assign IPv6 462 prefix greater than /64 for each subscriber, this 464XLAT 463 architecture can separate IPv6 prefix for native IPv6 packets and 464 XLAT prefix for IPv4/IPv6 translation packets. Accordingly, it 465 can identify the type of packets ("native IPv6 packets" and 466 "IPv4/IPv6 translation packets"), and implement traffic 467 engineering based on IPv6 prefix. 469 This 464XLAT architecture has two capabilities. One is a IPv6 -> 470 IPv4 -> IPv6 translation for sharing global IPv4 addresses, another 471 is a IPv4 -> IPv6 translation for reaching IPv6-only servers from 472 IPv4-only clients that can not support IPv6. IPv4-only clients must 473 be support through the long period of global transition to IPv6. 475 9. Security Considerations 477 To implement a PLAT, see security considerations presented in Section 478 5 of [RFC6146]. 480 To implement a CLAT, see security considerations presented in Section 481 7 of [RFC6145]. The CLAT MAY comply with [RFC6092]. 483 10. IANA Considerations 485 This document has no actions for IANA. 487 11. Acknowledgements 489 The authors would like to thank JPIX NOC members, JPIX 464XLAT trial 490 service members, Seiichi Kawamura, and Dan Drown for their helpful 491 comments. 493 12. References 495 12.1. Normative References 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 501 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 502 October 2010. 504 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 505 IPv4/IPv6 Translation", RFC 6144, April 2011. 507 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 508 Algorithm", RFC 6145, April 2011. 510 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 511 NAT64: Network Address and Protocol Translation from IPv6 512 Clients to IPv4 Servers", RFC 6146, April 2011. 514 12.2. Informative References 516 [I-D.arkko-ipv6-only-experience] 517 Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 518 Network", draft-arkko-ipv6-only-experience-04 (work in 519 progress), October 2011. 521 [I-D.ietf-behave-nat64-discovery-heuristic] 522 Savolainen, T. and J. Korhonen, "Discovery of a Network- 523 Specific NAT64 Prefix using a Well-Known Name", 524 draft-ietf-behave-nat64-discovery-heuristic-04 (work in 525 progress), December 2011. 527 [I-D.ietf-v6ops-3gpp-eps] 528 Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 529 Bajko, G., and K. Iisakkila, "IPv6 in 3GPP Evolved Packet 530 System", draft-ietf-v6ops-3gpp-eps-08 (work in progress), 531 September 2011. 533 [I-D.mdt-softwire-mapping-address-and-port] 534 Troan, O., "Mapping of Address and Port (MAP)", 535 draft-mdt-softwire-mapping-address-and-port-02 (work in 536 progress), November 2011. 538 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 539 Customer Premises Equipment (CPE) for Providing 540 Residential IPv6 Internet Service", RFC 6092, 541 January 2011. 543 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 544 Beijnum, "DNS64: DNS Extensions for Network Address 545 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 546 April 2011. 548 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 549 Stack Lite Broadband Deployments Following IPv4 550 Exhaustion", RFC 6333, August 2011. 552 Authors' Addresses 554 Masataka Mawatari 555 Japan Internet Exchange Co.,Ltd. 556 KDDI Otemachi Building 19F, 1-8-1 Otemachi, 557 Chiyoda-ku, Tokyo 100-0004 558 JAPAN 560 Phone: +81 3 3243 9579 561 Email: mawatari@jpix.ad.jp 563 Masanobu Kawashima 564 NEC AccessTechnica, Ltd. 565 800, Shimomata 566 Kakegawa-shi, Shizuoka 436-8501 567 JAPAN 569 Phone: +81 537 23 9655 570 Email: kawashimam@vx.jp.nec.com 572 Cameron Byrne 573 T-Mobile USA 574 Bellevue, Washington 98006 575 USA 577 Email: cameron.byrne@t-mobile.com