idnits 2.17.1 draft-ietf-v6ops-incremental-cgn-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 : ---------------------------------------------------------------------------- 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 (June 18, 2010) is 5059 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2766 (Obsoleted by RFC 4966) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Jiang 2 Internet Draft D. Guo 3 Intended status: Informational Huawei Technologies Co., Ltd 4 Expires: December 22, 2010 B. Carpenter 5 University of Auckland 6 June 18, 2010 8 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 9 draft-ietf-v6ops-incremental-cgn-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is 19 at http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 This Internet-Draft will expire on December 22, 2010. 28 Copyright Notice 30 Copyright (c) 2010 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 Global IPv6 deployment was slower than originally expected in the 46 last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 47 transition issues become more critical and complicated. Host-based 48 transition mechanisms are not able to meet the requirements while 49 most end users are not sufficiently expert to configure or maintain 50 these transition mechanisms. Carrier-Grade NAT (CGN) with integrated 51 transition mechanisms can simplify the operation of end users during 52 the IPv4/IPv6 migration or coexistence period. This document proposes 53 an incremental CGN approach for IPv6 transition. It can provide IPv6 54 access services for IPv6-enabled end hosts and IPv4 access services 55 for IPv4 end hosts while remaining most of legacy IPv4 ISP networks 56 unchanged. It is suitable for the initial stage of IPv4/IPv6 57 migration. Unlike NAT444 CGN alone, it also supports and encourages 58 transition towards dual-stack or IPv6-only ISP networks. A smooth 59 transition mechanism is also described in this document. It 60 introduces an integrated configurable CGN device and an adaptive Home 61 Gateway (HG) device. Both HG and CGN are re-usable devices during 62 different transition periods. It avoid potential multiple upgrade. 63 ISPs have NOT to make a big transition decision. It enables IPv6 64 migration to be incrementally achieved according to the real user 65 requirements. So ISPs have NOT to make a big transition decision. 67 Table of Contents 69 1. Introduction.................................................3 70 2. An Incremental CGN Approach..................................4 71 2.1. Incremental CGN Approach Overview.......................4 72 2.2. Choice of tunnelling technology.........................5 73 2.3. Behaviour of Dual-stack Home Gateway....................6 74 2.4. Behaviour of Dual-stack CGN.............................6 75 2.5. Impact for existing end hosts and remaining networks....7 76 2.6. IPv4/IPv6 intercommunication............................7 77 2.7. Discussion..............................................7 78 3. Smooth transition towards IPv6 infrastructure................8 79 4. Security Considerations......................................9 80 5. IANA Considerations..........................................9 81 6. Acknowledgements.............................................9 82 7. Change Log [RFC Editor please remove].......................10 83 8. References..................................................11 84 8.1. Normative References...................................11 85 8.2. Informative References.................................11 86 Author's Addresses.............................................14 88 1. Introduction 90 Up to now, global IPv6 deployment does not happen as was expected 10 91 years ago. The progress was much slower than originally expected. 92 Network providers were hesitant to take the first move while IPv4 was 93 and is still working well. However, IPv4 address exhaustion is now 94 confirmed to happen soon. The dynamically-updated IPv4 Address Report 95 [IPUSAGE] has analyzed this issue. It predicts early 2011 for IANA 96 unallocated address pool exhaustion and middle 2012 for RIR 97 unallocated address pool exhaustion. Based on this fact, the Internet 98 industry appears to have reached consensus that global IPv6 99 deployment is inevitable and has to be done quite quickly. 101 IPv4/IPv6 transition issues therefore become more critical and 102 complicated for the soon-coming global IPv6 deployment. Host-based 103 transition mechanisms alone are not able to meet the requirements in 104 all cases. Therefore, network supporting functions and/or new 105 transition mechanisms with simple user-side operation are needed. 107 Carrier-Grade NAT (CGN) [I-D.nishitani-cgn], also called NAT444 CGN, 108 alone creates operational problems, but does nothing to help 109 IPv4/IPv6 transition. In fact it allows ISPs to delay the transition, 110 and therefore causes double transition costs (once to add CGN, and 111 again to support IPv6). 113 CGN that integrates multiple transition mechanisms can simplify the 114 operation of end user services during the IPv4/IPv6 migration or 115 coexistence period. CGNs are deployed on the network side and 116 managed/maintained by professionals. On the user side, new Home 117 Gateway (HG) devices may be needed too. They may be provided by 118 network providers, depending on the specific business model. Dual- 119 stack lite [I-D.ietf-softwire-dual-stack-lite], also called DS-Lite, 120 is a CGN-based solution that supports transition, but it requires the 121 ISP to upgrade its network to IPv6 immediately. Many ISPs hesitate to 122 do this as the first step. Theoretically, DS-Lite can be used with 123 double encapsulation (IPv4-in-IPv6-in-IPv4) but this seems even less 124 likely to be accepted by an ISP and is not discussed further. 126 This document proposes an incremental CGN approach for IPv6 127 transition. The approach is similar to DS-Lite, but the other way 128 around. Technically, it mainly combines v4-v4 NAT with v6-over-v4 129 tunnelling functions along with some minor adjustment. It can provide 130 IPv6 access services for IPv6-enabled end hosts and IPv4 access 131 services for IPv4 end hosts, while leaving most of legacy IPv4 ISP 132 networks unchanged. The deployment of this technology does not affect 133 legacy IPv4 hosts with global IPv4 addresses at all. It is suitable 134 for the initial stage of IPv4/IPv6 migration. It also supports 135 transition towards dual-stack or IPv6-only ISP networks. 137 A smooth transition mechanism is also described in this document. It 138 introduces an integrated configurable CGN device and an adaptive HG 139 device. Both CGN and HG are re-usable devices during different 140 transition periods. It avoid potential multiple upgrade. It enables 141 IPv6 migration to be incrementally achieved according to the real 142 user requirements. So ISPs have NOT to make a big transition 143 decision. 145 2. An Incremental CGN Approach 147 Most ISP networks are still IPv4. Network providers are starting to 148 provide IPv6 access services for end users. However, at the initial 149 stage of IPv4/IPv6 migration, IPv4 connectivity and traffic would be 150 the majority for most ISP networks. ISPs would like to minimize the 151 changes on their IPv4 networks. Switching the whole ISP network into 152 IPv6-only would be considered as a radical strategy. Switching the 153 whole ISP network to dual stack is less radical, but introduces 154 operational costs and complications. Although some ISPs have 155 successfully deployed dual stack routers, others prefer not to do 156 this as their first step in IPv6. However, they currently face two 157 urgent pressures - to compensate for an immediate shortage of IPv4 158 addresses by deploying some method of address sharing, and to prepare 159 actively for the deployment of IPv6 address space and services. ISPs 160 facing only one pressure out of two could adopt either CGN (for 161 shortage of IPv6 addresses) or 6rd (to provide IPv6 connectivity 162 services). The approach described in this draft is targeting to 163 addresses both of these pressures at the same time by combining v4-v4 164 CGN with v6-over-v4 tunnelling technologies. 166 2.1. Incremental CGN Approach Overview 168 The incremental CGN approach we propose is illustrated as the 169 following figure. 171 +-------------+ 172 |IPv6 Internet| 173 +-------------+ 174 | 175 +-------------+----------+ 176 +-----+ +--+ | IPv4 ISP +--+--+ | +--------+ 177 |v4/v6|----|DS|=====+==========| CGN |-------+---| IPv4 | 178 |Host | |HG| | Network +-----+ | | |Internet| 179 +-----+ +--+ +--------------------+---+ +--------+ 180 _ _ _ _ _ _ _ _ _ _ _ | 181 ()_6_o_4_ _t_u_n_n_e_l_() +---------------------+ 182 | Existing IPv4 hosts | 183 +---------------------+ 185 Figure 1: incremental CGN approach with IPv4 ISP network 187 DS HG = Dual-Stack Home Gateway (CPE). 189 As showed in the above figure, the ISP has not significantly changed 190 its IPv4 network. This approach enables IPv4 hosts to access the IPv4 191 Internet and IPv6 hosts to access the IPv6 Internet. A dual stack 192 host can be treated as an IPv4 host when it uses IPv4 access service 193 and as an IPv6 host when it uses IPv6 access service. In order to 194 enable IPv4 hosts to access IPv6 Internet and IPv6 hosts to access 195 IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its replacement) can be 196 integrated with CGN. The integration of such mechanisms is out of 197 scope for this document 199 Two new types of devices need to be deployed in this approach: a 200 dual-stack home gateway, which may follow the requirements of 201 [I-D.ietf-v6ops-ipv6-cpe-router], and dual-stack CGN. The dual-stack 202 home gateway integrates IPv4 forwarding and v6-over-v4 tunnelling 203 functions. It may integrate v4-v4 NAT function, too. The dual-stack 204 CGN integrates v6-over-v4 tunnelling and v4-v4 CGN functions. 206 2.2. Choice of tunnelling technology 208 In principle, this model will work with any form of tunnel between 209 the DS HG and the dual-stack CGN. However, tunnels that require 210 individual configuration are clearly undesirable because of their 211 operational cost. Configured tunnels based directly on [RFC4213] are 212 therefore not suitable. A tunnel broker according to [RFC3053] would 213 also have high operational costs. 215 Modified 6RD [RFC5569, I-D.ietf-softwire-ipv6-6rd] technology appears 216 suitable to support v6-over-v4 tunnelling with low operational cost. 217 Modified GRE [RFC2784] with additional auto-configuration mechanism 218 is also suitable to support v6-over-v4 tunnelling. Other tunnelling 219 mechanisms such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site 220 Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214] or Virtual 221 Enterprise Traversal (VET) [RFC5558] are also considered. If the ISP 222 has an entirely MPLS infrastructure between the HG and the dual-stack 223 CGN, it would also be possible to consider a 6PE [RFC4798] tunnel 224 directly over MPLS. This would, however, only be suitable for an 225 advanced HG that is unlikely to be found as a home gateway, and is 226 not further discussed here. 228 2.3. Behaviour of Dual-stack Home Gateway 230 When a dual-stack home gateway receives a data packet from an end 231 host, it firstly checks whether the packet is IPv4 or IPv6. For IPv4 232 data, the HG can directly forward it to CGN if there is no v4-v4 NAT 233 running on the HG. Or the HG translates packet source address from a 234 HG-scope private IPv4 address into a CGN-scope private IPv4 address, 235 then forwards it to CGN. The HG records the v4-v4 address mapping 236 information for inbound packets, just like normal NAT does. 238 For IPv6 data, the HG needs to encapsulate the data into an IPv4 239 tunnel, which has the dual-stack CGN as the other end. Then the HG 240 sends the new IPv4 packet towards CGN. 242 The HG records the mapping information between the tunnel and the 243 source IPv6 address for inbound packets if HG uplinks to more than 244 one CGN. Detailed considerations for the use of multiple CGNs by one 245 HG are for further study. 247 2.4. Behaviour of Dual-stack CGN 249 When a dual-stack CGN receives a data packet from a dual-stack home 250 gateway, it firstly checks whether the packet is a normal IPv4 packet 251 or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN 252 translates packet source address from a CGN-scope private IPv4 253 address into a public IPv4 address, and then send it to IPv4 254 Internet. The CGN records the v4-v4 address mapping information for 255 inbound packets, just like normal NAT does. For a v6-over-v4 tunnel 256 packet, the CGN needs to decapsulate it into the original IPv6 packet 257 and then send it to IPv6 Internet. The CGN records the mapping 258 information between the tunnel and the source IPv6 address for 259 inbound packets. 261 Depending on the deployed location of the CGN, it may use v6-over-v4 262 tunnels to connect to the IPv6 Internet. 264 2.5. Impact for existing end hosts and remaining networks 266 This approach does not affect the remaining networks at all. Legacy 267 IPv4 ISP networks and their IPv4 devices remain in use. The existing 268 IPv4 hosts, shown as the right box in Figure 1, either having global 269 IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it 270 is now. Of course, these hosts, if they are upgraded to become dual- 271 stack hosts, can access IPv6 Internet through IPv4 ISP network by 272 using IPv6-over-IPv4 tunnel technologies. 274 2.6. IPv4/IPv6 intercommunication 276 Although IPv6-only public services are not expected as long as there 277 is an IPv4-only customer base in the world, for obvious commercial 278 reasons. However, IPv4/IPv6 intercommunication may become issues in 279 many scenarios. 281 Each ISP can provide its IPv6-only customers with a network-layer 282 translation service to satisfy this need. Such a service is not fully 283 defined at this time, so we refer to it non-specifically as "NAT64". 284 Current work in the IETF is focussed on one particular proposal 285 [I-D.ietf-behave-v6v4-xlate-stateful]. The NAT64 service can be 286 provided as a common service located at the border between the ISP 287 and the IPv4 Internet, beyond the dual stack CGN from the customer's 288 viewpoint. It may be integrated into CGN devices too. 290 [I-D.boucadair-dslite-interco-v4v6] describes a proposal to enhance 291 DS-lite solution with an additional feature to ease interconnection 292 between IPv4 and IPv6 realms. Furthermore, home users may encounter 293 the problem of reaching legacy IPv4-only public services from IPv6- 294 only clients. This problem could already exist in Phase 1, but will 295 become more serious as time goes on. 297 2.7. Discussion 299 For IPv4 traffic, this approach inherits all the problems of CGN 300 (e.g., scaling, and the difficulty of supporting well-known ports for 301 inbound traffic). Application layer problems created by double NAT 302 are for further study. 304 If a different technology than v4-v4 NAT is chosen for IPv4 address 305 sharing, for example [I-D.ymbk-aplusp], the present approach could be 306 suitably modified, for example replacing the v4-v4 NAT function by 307 the A+P gateway function. 309 However, for IPv6 traffic, a user behind the DS HG will see normal 310 IPv6 service. We therefore observe that an IPv6 tunnel MTU of at 311 least 1500 bytes would ensure that the mechanism does not cause 312 excessive fragmentation of IPv6 traffic nor excessive IPv6 path MTU 313 discovery interactions. 315 However, for IPv6 traffic, a user behind the DS HG will see normal 316 IPv6 service. This, and the absence of NAT problems for IPv6, will 317 create an incentive for users and application service providers to 318 prefer IPv6. 320 ICMP filtering [RFC4890] function may be included as part of CGN 321 functions. 323 3. Smooth transition towards IPv6 infrastructure 325 This incremental CGN approach can easily be transited from NAT444 CGN 326 or 6rd. NAT444 CGN solves the public address shortage issues in the 327 current IPv4 infrastructure. However, it does not contribute towards 328 IPv6 at all. This incremental CGN approach can inherit NAT444 CGN 329 function while providing overlay IPv6 services. 6rd mechanism can 330 also transform into this incremental CGN with small modifications. 331 One consideration is that home gateways also have to be changed 332 correspondently. 334 This incremental CGN can also easily be transited into IPv6-enabled 335 infrastructure, in which the ISP network is either dual-stack or 336 IPv6-only. For dual-stack ISP networks, dual-stack home gateways can 337 simply switch off the v6-over-v4 function and forward both IPv6 and 338 IPv4 traffic directly while the dual-stack CGN only keeps its v4-v4 339 NAT function. However, this is considered an unlikely choice, since 340 we expect ISPs to choose the approach described here because they 341 want to avoid dual-stack deployment completely. For IPv6-only ISP 342 networks, the DS-Lite solution also needs dual-stack home gateway and 343 CGN devices. 345 The best business model for this approach is that an integrated 346 configurable CGN device and an adaptive HG device. The integrated CGN 347 hardware may be integrated multiple functions, include NAT444 CGN, 348 6rd router, incremental CGN, DS-Lite CGN and dual-stack forwarding. 349 It could act as different device with only software configuration 350 change while the hardware and its physical position/connectivity 351 remains no change at all. HG has also integrated these correspondent 352 functions, and be able to automatically detect the change on the CGN 353 side. 355 For example, the appearance of IPv6 Route Advertisement messages or 356 DHCPv6 messages can be used as a signal of DS-Lite CGN. Then when an 357 ISP decides to switch from incremental CGN to DS-Lite CGN, it may be 358 that only a configuration change or a minor software update is needed 359 on the CGNs. The home gateway will then detect this change and switch 360 automatically to DS-Lite mode. The only impact on the home user will 361 be to receive a different IPv6 prefix. 363 In this smooth transition model, both CGN and HG are re-usable 364 devices during different transition periods. It avoid potential 365 multiple upgrade. It enables IPv6 migration to be incrementally 366 achieved according to the real user requirements. ISPs have NOT to 367 make a big transition decision. 369 4. Security Considerations 371 Security issues associated with NAT have been documented in [RFC2663] 372 and [RFC2993]. 374 Further security analysis will be needed to understand double NAT 375 security issues and tunnel security issues. However, since the tunnel 376 proposed here exists entirely within a single ISP network, between 377 the HG/CPE and the CGN, the threat model is relatively simple. 378 [RFC4891] describes how to protect tunnels using IPSec, but it is not 379 clear whether this would be an important requirement. An ISP could 380 deem its infrastructure to have sufficient security without 381 additional protection of the tunnels. 383 The dual-stack home gateway will need to provide basic security for 384 IPv6 [I-D.ietf-v6ops-cpe-simple-security]. Other aspects are 385 described in [RFC4864]. 387 5. IANA Considerations 389 This draft does not request any IANA action. 391 6. Acknowledgements 393 Useful comments were made by Fred Baker, Dan Wing, Fred Templin, 394 Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair, 395 Shin Miyakawa and other members of the IETF V6OPS working group. 397 7. Change Log [RFC Editor please remove] 399 draft-jiang-incremental-cgn-00, original version, 2009-02-27 401 draft-jiang-v6ops-incremental-cgn-00, revised after comments at 402 IETF74, 2009-04-23 404 draft-jiang-v6ops-incremental-cgn-01, revised after comments at v6ops 405 mailing list, 2009-06-30 407 draft-jiang-v6ops-incremental-cgn-02, remove normative parts (to be 408 documented in other WGs), 2009-07-06 410 draft-jiang-v6ops-incremental-cgn-03, revised after comments at v6ops 411 mailing list, 2009-09-24 413 draft-ietf-v6ops-incremental-cgn-00, accepted as v6ops wg docuemtn, 414 2009-11-17 416 draft-ietf-v6ops-incremental-cgn-01, revised after comments at v6ops 417 mailing list, 2010-06-21 419 8. References 421 8.1. Normative References 423 [RFC2529] B. Carpenter, and C. Jung, "Transmission of IPv6 over IPv4 424 Domains without Explicit Tunnels", RFC2529, March 1999. 426 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina, 427 "Generic Routing Encapsulation (GRE)", RFC 2784, March 428 2000. 430 8.2. Informative References 432 [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address 433 Translator (NAT) Terminology and Considerations", RFC 2663, 434 August 1999. 436 [RFC2766] G. Tsirtsis and P. Srisuresh, "Network Address Translation 437 - Protocol Translation (NAT-PT)", RFC 2766, February 2000. 439 [RFC2993] T. Hain, "Architectural Implications of NAT", RFC 2993, 440 November 2000. 442 [RFC3053] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6 443 Tunnel Broker", RFC 3053, January 2001. 445 [RFC3056] B. Carpenter and K. Moore, "Connection of IPv6 Domains via 446 IPv4 Clouds", RFC 3056, February 2001. 448 [RFC4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms 449 for IPv6 Hosts and Routers", RFC 4213, October 2005. 451 [RFC4798] J. De Clercq, D. Ooms, S. Prevost and F. Le Faucheur, 452 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 453 Edge Routers (6PE)", RFC 4798, February 2007. 455 [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter and E. 456 Klein, "Local Network Protection for IPv6", RFC 4864, May 457 2007. 459 [RFC4890] E. Davies and J. Mohacsi, "Recommendations for Filtering 460 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 462 [RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 463 RFC4891, May 2007. 465 [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address 466 Translator - Protocol Translator (NAT-PT) to Historic 467 Status", RFC 4966, July 2007. 469 [RFC5214] F. Templin, T. Gleeson and D. Thaler, "Intra-Site Automatic 470 Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. 472 [RFC5558] F. Templin, "Virtual Enterprise Traversal (VET)", RFC 5558, 473 February 2010. 475 [RFC5569] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures 476 (6rd)", RFC 5569, January 2010. 478 [IPUSAGE] G. Huston, IPv4 Address Report, March 2009, 479 http://www.potaroo.net/tools/ipv4/index.html. 481 [I-D.ietf-softwire-dual-stack-lite] 482 A. Durand, "Dual-stack lite broadband deployments post IPv4 483 exhaustion", draft-ietf-softwire-dual-stack-lite, work in 484 progress. 486 [I-D.ietf-softwire-ipv6-6rd] 487 W. Townsley and O. Troan, "IPv6 via IPv4 Service Provider 488 Networks '6rd'", draft-ietf-softwire-ipv6-6rd, work in 489 progress. 491 [I-D.ietf-v6ops-ipv6-cpe-router] 492 H. Singh, W. Beebee, C. Donley, B. Stark and O. Troan, 493 "IPv6 CPE Router Recommendations", draft-ietf-v6ops-ipv6- 494 cpe-router, work in progress. 496 [I-D.ietf-v6ops-cpe-simple-security] 497 J. Woodyatt, "Recommended Simple Security Capabilities in 498 Customer Premises Equipment for Providing Residential IPv6 499 Internet Service", draft-ietf-v6ops-cpe-simple-security, 500 work in progress. 502 [I-D.ietf-behave-v6v4-xlate-stateful] 503 M. Bagnulo, P. Matthews and I. van Beijnum, "NAT64: Network 504 Address and Protocol Translation from IPv6 Clients to IPv4 505 Servers", draft-ietf-behave-v6v4-xlate-stateful, work in 506 progress. 508 [I-D.nishitani-cgn] 509 I. Yamagata, T. Nishitani, S. Miyahawa, A. nakagawa and H. 510 Ashida, "Common requirements for IP address sharing 511 schemes", draft-nishitani-cgn, work in progress. 513 [I-D.ymbk-aplusp] 514 R. Bush, "The A+P Approach to the IPv4 Address Shortage", 515 draft-ymbk-aplusp, work in progress. 517 [I-D.boucadair-dslite-interco-v4v6] 518 M. Boucadair, et al, "Stateless IPv4-IPv6 Interconnection 519 in the Context of DS-lite Deployment", draft-boucadair- 520 dslite-interco-v4v6, work in progress. 522 Author's Addresses 524 Sheng Jiang 525 Huawei Technologies Co., Ltd 526 Huawei Building, No.3 Xinxi Rd., 527 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 528 P.R. China 529 Email: shengjiang@huawei.com 531 Dayong Guo 532 Huawei Technologies Co., Ltd 533 Huawei Building, No.3 Xinxi Rd., 534 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 535 P.R. China 536 Email: guoseu@huawei.com 538 Brian Carpenter 539 Department of Computer Science 540 University of Auckland 541 PB 92019 542 Auckland, 1142 543 New Zealand 544 Email: brian.e.carpenter@gmail.com