idnits 2.17.1 draft-ietf-v6ops-incremental-cgn-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 (January 4, 2011) is 4854 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: July 4, 2011 B. Carpenter 5 University of Auckland 6 January 4, 2011 8 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 9 draft-ietf-v6ops-incremental-cgn-03.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 July 4, 2011. 28 Copyright Notice 30 Copyright (c) 2011 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. As IPv4 46 address exhaustion approaches, IPv4 to IPv6 transition issues become 47 more critical and less tractable. Host-based transition mechanisms 48 used in dual stack environments cannot meet all transition 49 requirements. Most end users are not sufficiently expert to configure 50 or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) 51 devices with integrated transition mechanisms can reduce the 52 operational changes required during the IPv4 to IPv6 migration or 53 coexistence period. 55 This document proposes an incremental CGN approach for IPv6 56 transition. It can provide IPv6 access services for IPv6 hosts and 57 IPv4 access services for IPv4 hosts, while leaving much of a legacy 58 ISP network unchanged during the initial stage of IPv4 to IPv6 59 migration. Unlike CGN alone, incremental CGN also supports and 60 encourages smooth transition towards dual-stack or IPv6-only ISP 61 networks. An integrated configurable CGN device and an adaptive Home 62 Gateway (HG) device are described. Both are re-usable during 63 different transition phases, avoiding multiple upgrades. This enables 64 IPv6 migration to be incrementally achieved according to real user 65 requirements. 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 tunneling technology..........................5 73 2.3. Behavior of Dual-stack Home Gateway.....................6 74 2.4. Behavior of Dual-stack CGN..............................7 75 2.5. Impact for existing hosts and unchanged networks........7 76 2.6. IPv4/IPv6 intercommunication............................7 77 2.7. Discussion..............................................8 78 3. Smooth transition towards IPv6 infrastructure................9 79 4. Security Considerations.....................................10 80 5. IANA Considerations.........................................11 81 6. Acknowledgements............................................11 82 7. Change Log [RFC Editor please remove].......................11 83 8. References..................................................12 84 8.1. Normative References...................................12 85 8.2. Informative References.................................12 86 Author's Addresses.............................................15 88 1. Introduction 90 Global IPv6 deployment did not happen as was forecast 10 years ago. 91 Network providers were hesitant to make the first move while IPv4 was 92 and is still working well. However, IPv4 address exhaustion is 93 imminent. The dynamically-updated IPv4 Address Report [IPUSAGE] has 94 analyzed this issue. It predicts early 2011 for IANA unallocated 95 address pool exhaustion and middle 2012 for RIR unallocated address 96 pool exhaustion. Based on this fact, the Internet industry appears to 97 have reached consensus that global IPv6 deployment is inevitable and 98 has to be done expeditiously. 100 IPv4 to IPv6 transition issues therefore become more critical and 101 complicated for the approaching global IPv6 deployment. Host-based 102 transition mechanisms alone are not able to meet the requirements in 103 all cases. Therefore, network-based supporting functions and/or new 104 transition mechanisms with simple user-side operation are needed. 106 Carrier-Grade NAT (CGN) [I-D.nishitani-cgn], also called NAT444 CGN 107 or Large Scale NAT, compounds IPv4 operational problems when used 108 alone, but does nothing to encourage IPv4 to IPv6 transition. 109 Deployment of NAT444 CGN allows ISPs to delay the transition, and 110 therefore causes double transition costs (once to add CGN, and again 111 to support IPv6). 113 CGN deployments that integrate multiple transition mechanisms can 114 simplify the operation of end user services during the IPv4 to IPv6 115 migration and coexistence periods. CGNs are deployed on the network 116 side and managed/maintained by professionals. On the user side, new 117 Home 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 in this 125 document. 127 This document proposes an incremental CGN approach for IPv6 128 transition. It does not define any new protocols or mechanisms, but 129 describes how to combine existing proposals in an incremental 130 deployment. The approach is similar to DS-Lite, but the other way 131 around. It mainly combines v4-v4 NAT with v6-over-v4 tunneling 132 functions. It can provide IPv6 access services for IPv6-enabled hosts 133 and IPv4 access services for IPv4 hosts, while leaving most of legacy 134 IPv4 ISP networks unchanged. The deployment of this technology does 135 not affect legacy IPv4 hosts with global IPv4 addresses at all. It is 136 suitable for the initial stage of IPv4 to IPv6 migration. It also 137 supports transition towards dual-stack or IPv6-only ISP networks. 139 A smooth transition mechanism is also described in this document. It 140 introduces an integrated configurable CGN device and an adaptive HG 141 device. Both CGN and HG are re-usable devices during different 142 transition periods, so they do not need to be replaced as the 143 transition proceeds. This enables IPv6 migration to be incrementally 144 achieved according to the real user requirements. 146 2. An Incremental CGN Approach 148 Today, most consumers primarily use IPv4. Network providers are 149 starting to provide IPv6 access services for end users. At the 150 initial stage of IPv4 to IPv6 migration, IPv4 connectivity and 151 traffic would continue to represent the majority of traffic for most 152 ISP networks. ISPs would like to minimize the changes to their IPv4 153 networks. Switching the whole ISP network into IPv6-only would be 154 considered as a radical strategy. Switching the whole ISP network to 155 dual stack is less radical, but introduces operational costs and 156 complications. Although some ISPs have successfully deployed dual 157 stack networks, others prefer not to do this as their first step in 158 IPv6. However, they currently face two urgent pressures - to 159 compensate for an immediate shortage of IPv4 addresses by deploying 160 some method of address sharing, and to prepare actively for the use 161 of deployment of IPv6 address space and services. ISPs facing only 162 one pressure out of two could adopt either CGN (for shortage of IPv4 163 addresses) or 6rd (to provide IPv6 connectivity services). The 164 approach described in this draft is intended to address both of these 165 pressures at the same time by combining v4-v4 CGN with v6-over-v4 166 tunneling technologies. 168 2.1. Incremental CGN Approach Overview 170 The incremental CGN approach we propose is illustrated as the 171 following figure. 173 +-------------+ 174 |IPv6 Internet| 175 +-------------+ 176 | 177 +---------------+----------+ 178 +-----+ +--+ | IPv4 ISP +--+--+ | +--------+ 179 |v4/v6|---|DS|=======+============| CGN |-------+---| IPv4 | 180 |Host | |HG| | Network +-----+ | | |Internet| 181 +-----+ +--+ +----------------------+---+ +--------+ 182 _ _ _ _ _ _ _ _ _ _ _ | 183 ()_6_over_4_ _t_u_n_n_e_l_() +---------------------+ 184 | Existing IPv4 hosts | 185 +---------------------+ 187 Figure 1: incremental CGN approach with IPv4 ISP network 189 DS HG = Dual-Stack Home Gateway (CPE - Customer Premises Equipment). 191 As shown in the above figure, the ISP has not significantly changed 192 its IPv4 network. This approach enables IPv4 hosts to access the IPv4 193 Internet and IPv6 hosts to access the IPv6 Internet. A dual stack 194 host is treated as an IPv4 host when it uses IPv4 access service and 195 as an IPv6 host when it uses an IPv6 access service. In order to 196 enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to 197 access IPv4 Internet, NAT64 can be integrated with the CGN; see 198 Section 2.6 for details regarding IPv4/IPv6 intercommunication. The 199 integration of such mechanisms is out of scope for this document. 201 Two types of device need to be deployed in this approach: a dual- 202 stack home gateway (HG), and a dual-stack CGN. The dual-stack home 203 gateway integrates both IPv6 and IPv4 forwarding and v6-over-v4 204 tunneling functions. It should follow the requirements of 205 [I-D.ietf-v6ops-ipv6-cpe-router], including IPv6 prefix delegation. 206 It may integrate v4-v4 NAT functionality, too. The dual-stack CGN 207 integrates v6-over-v4 tunneling and v4-v4 CGN functions, as well as 208 standard IPv6 and IPv4 routing 210 The approach does not require any new mechanisms for IP packet 211 forwarding or encapsulation or decapsulation at tunnel end points. 212 The following sections describe how the HG and the incremental CGN 213 interact. 215 2.2. Choice of tunneling technology 217 In principle, this model will work with any form of tunnel between 218 the dual-stack HG and the dual-stack CGN. However, tunnels that 219 require individual configuration are clearly undesirable because of 220 their operational cost. Configured tunnels based directly on 221 [RFC4213] are therefore not suitable. A tunnel broker according to 222 [RFC3053] would also have high operational costs and be unsuitable 223 for home users. 225 6rd [RFC5569, RFC5969] technology appears suitable to support v6- 226 over-v4 tunneling with low operational cost. GRE [RFC2784] with an 227 additional auto-configuration mechanism is also able to support v6- 228 over-v4 tunneling. Other tunneling mechanisms such as 6over4 229 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic Tunnel Addressing 230 Protocol (ISATAP) [RFC5214] or Virtual Enterprise Traversal (VET) 231 [RFC5558] could be considered. If the ISP has an entirely MPLS 232 infrastructure between the HG and the dual-stack CGN, it would also 233 be possible to use a 6PE [RFC4798] tunnel directly over MPLS. This 234 would, however, only be suitable for an advanced HG that is unlikely 235 to be found as a consumer device, and is not further discussed here. 236 To simplify the discussion, we assume the use of 6rd. 238 2.3. Behavior of Dual-stack Home Gateway 240 When a dual-stack home gateway receives a data packet from a host, it 241 will determine whether the packet is an IPv4 or IPv6 packet. The 242 packet will be handled by an IPv4 or IPv6 stack as appropriate. For 243 IPv4, and in the absence of v4-v4 NAT on the HG, the stack will 244 simply forward the packet to the CGN, which will normally be the IPv4 245 default router. If v4-v4 NAT is enabled, the HG translates the packet 246 source address from a HG-scope private IPv4 address into a CGN-scope 247 IPv4 address, performs port mapping if needed, and then forwards the 248 packet towards the CGN. The HG records the v4-v4 address and port 249 mapping information for inbound packets, like any other NAT. 251 For IPv6, the HG needs to encapsulate the data into an IPv4 tunnel 252 packet, which has the dual-stack CGN as the IPv4 destination. The HG 253 sends the new IPv4 packet towards the CGN, for example using 6rd. 255 If the HG is linked to more than one CGN, it will record the mapping 256 information between the tunnel and the source IPv6 address for 257 inbound packets. Detailed considerations for the use of multiple CGNs 258 by one HG are for further study. 260 IPv4 packets from the CGN, and encapsulated IPv6 packets from the 261 CGN, will be translated or decapsulated according to the stored 262 mapping information and forwarded to the customer side of the HG. 264 2.4. Behavior of Dual-stack CGN 266 When a dual-stack CGN receives an IPv4 data packet from a dual-stack 267 home gateway, it will determine whether the packet is a normal IPv4 268 packet, which is non-encapsulated, or a v6-over-v4 tunnel packet 269 addressed to a tunnel end point within the CGN. For a normal IPv4 270 packet, the CGN translates the packet source address from a CGN-scope 271 IPv4 address into a public IPv4 address, performs port mapping if 272 necessary, and then forwards it normally to the IPv4 Internet. The 273 CGN records the v4-v4 address and port mapping information for 274 inbound packets, just like a normal NAT does. For a v6-over-v4 tunnel 275 packet, the tunnel end point within the CGN will decapsulate it into 276 the original IPv6 packet and then forward it to the IPv6 Internet. 277 The CGN records the mapping information between the tunnel and the 278 source IPv6 address for inbound packets. 280 Depending on the deployed location of the CGN, it may use a further 281 v6-over-v4 tunnel to connect to the IPv6 Internet. 283 Packets from the IPv4 Internet will be appropriately translated by 284 the CGN and forwarded to the HG, and packets from the IPv6 Internet 285 will be tunneled to the appropriate HG, using the stored mapping 286 information as necessary. 288 2.5. Impact for existing hosts and unchanged networks 290 This approach does not affect the unchanged parts of ISP networks at 291 all. Legacy IPv4 ISP networks and their IPv4 devices remain in use. 292 The existing IPv4 hosts, shown as the lower right box in Figure 1, 293 either having global IPv4 addresses or behind v4-v4 NAT, can connect 294 to the IPv4 Internet as it is now. These hosts, if they are upgraded 295 to become dual-stack hosts, can access the IPv6 Internet through the 296 IPv4 ISP network by using IPv6-over-IPv4 tunnel technologies. (See 297 section 2.7 for a comment on MTU size.) 299 2.6. IPv4/IPv6 intercommunication 301 IPv6-only public services are not expected as long as there is 302 significant IPv4-only customer base in the world, for obvious 303 commercial reasons. However, IPv4/IPv6 intercommunication may become 304 issues in many scenarios. 306 The IETF is expected to standardize a recommended IPv4/IPv6 307 translation algorithm, sometimes referred to as NAT64. It is 308 specified in 309 o "Framework for IPv4/IPv6 Translation" 310 [I-D.ietf-behave-v6v4-framework] 311 o "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052] 312 o "DNS64: DNS extensions for Network Address Translation from IPv6 313 Clients to IPv4 Servers" [I-D.ietf-behave-dns64] 314 o "IP/ICMP Translation Algorithm" [I-D.ietf-behave-v6v4-xlate] 315 o "Stateful NAT64: Network Address and Protocol Translation from 316 IPv6 Clients to IPv4 Servers" 317 [I-D.ietf-behave-v6v4-xlate-stateful] 318 o "An FTP ALG for IPv6-to-IPv4 translation" [I-D.ietf-behave-ftp64] 320 The service, as described in the IETF's "Guidelines for Using IPv6 321 Transition Mechanisms during IPv6 Deployment" 322 [I-D.arkko-ipv6-transition-guidelines], provides for stateless 323 translation between hosts in an IPv4-only domain or which offer an 324 IPv4-only service and hosts with an IPv4-embedded IPv6 address in an 325 IPv6-only domain. It additionally provide access from IPv6 hosts with 326 general format addresses to hosts in an IPv4-only domain or which 327 offer an IPv4-only service. It does not provide any-to-any 328 translation. One result is that client-only hosts in the IPv6 domain 329 gain access to IPv4 services through stateful translation. Another 330 result is that the IPv6 network operator has the option of moving 331 servers into the IPv6-only domain while retaining accessibility for 332 IPv4-only clients, through stateless translation of an IPv4-embedded 333 IPv6 address. 335 Also, "Architectural Implications of NAT" [RFC2993] applies across 336 the service just as in IPv4/IPv4 translation: apart from the fact 337 that a system with an IPv4-embedded IPv6 address is reachable across 338 the NAT, which is unlike IPv4, any assumption on the application's 339 part that a local address is meaningful to a remote peer, and any use 340 of an IP address literal in the application payload, is a source of 341 service issues. In general, the recommended mitigation for this is 343 o Ideally, applications should use DNS names rather than IP address 344 literals in URLs, URIs, and referrals, and in general be network 345 layer agnostic. 346 o If they do not, the network may provide a relay or proxy that 347 straddles the domains. For example, an SMTP MTA with both IPv4 348 and IPv6 connectivity handles IPv4/IPv6 translation cleanly at the 349 application layer. 351 2.7. Discussion 353 For IPv4 traffic, the incremental CGN approach inherits all the 354 problems of CGN address sharing techniques 355 [I-D.ietf-intarea-shared-addressing-issues] (e.g., scaling, and the 356 difficulty of supporting well-known ports for inbound traffic). 357 Application layer problems created by double NAT are beyond the scope 358 of this document. 360 For IPv6 traffic, a user behind the DS HG will see normal IPv6 361 service. We observe that an IPv6 tunnel MTU of at least 1500 bytes 362 would ensure that the mechanism does not cause excessive 363 fragmentation of IPv6 traffic nor excessive IPv6 path MTU discovery 364 interactions. This, and the absence of NAT problems for IPv6, will 365 create an incentive for users and application service providers to 366 prefer IPv6. 368 ICMP filtering [RFC4890] may be included as part of CGN functions. 370 3. Smooth transition towards IPv6 infrastructure 372 Transition from pure NAT444 CGN or 6rd to the incremental CGN 373 approach is straightforward. The HG and CGN devices and their 374 locations do not have to be changed; only software upgrading may be 375 needed. In the ideal model, described below, even software upgrading 376 is not necessary; reconfiguration of the devices is enough. NAT444 377 CGN solves the public address shortage issues in the current IPv4 378 infrastructure. However, it does not contribute towards IPv6 379 deployment at all. The incremental CGN approach can inherit NAT444 380 CGN functions while providing overlay IPv6 services. 6rd mechanisms 381 can also transform smoothly into this incremental CGN model. However, 382 the home gateways need to be upgraded correspondingly to perform the 383 steps described below 385 The incremental CGN can also easily be transitioned to an IPv6- 386 enabled infrastructure, in which the ISP network is either dual-stack 387 or IPv6-only. 389 If the ISP prefers to move to dual-stack routing, the HG should 390 simply switch off its v6-over-v4 function when it observes native 391 IPv6 RA or DHCPv6 traffic, and then forward both IPv6 and IPv4 392 traffic directly, while the dual-stack CGN keeps only its v4-v4 NAT 393 function. 395 However, we expect ISPs to choose the approach described as 396 incremental CGN here because they intend to avoid dual-stack routing, 397 and to move incrementally from IPv4-only routing to IPv6-only 398 routing. In this case, the ideal model for the incremental CGN 399 approach is that of an integrated configurable CGN device and an 400 adaptive HG device. The integrated CGN device will be able to support 401 multiple functions, including NAT444 CGN, 6rd router (or an 402 alternative tunneling mechanism), DS-Lite, and dual-stack forwarding. 404 The HG has to integrate the corresponding functions, and be able to 405 detect relevant incremental changes on the CGN side. Typically the HG 406 will occasionally poll the CGN to discover which features are 407 operational. For example, starting from a pure IPv4-only scenario (in 408 which the HG treats the CGN only as an IPv4 default router), the HG 409 would discover by infrequent polling when 6rd became available. The 410 home user would then acquire an IPv6 prefix. At a later stage, the HG 411 would observe the appearance of native IPv6 Route Advertisement 412 messages or DHCPv6 messages to discover the availability of an IPv6 413 service including DS-Lite. Thus, when an ISP decides to switch from 414 incremental CGN to DS-Lite CGN, only a configuration change or a 415 minor software update is needed on the CGNs. The home gateway would 416 detect this change and switch automatically to DS-Lite mode. The only 417 impact on the home user will be to receive a different IPv6 prefix. 419 In the smooth transition model, both CGN and HG are re-usable devices 420 during different transition periods. This avoids potential multiple 421 upgrades. Different regions of the same ISP network may be at 422 different stages of the incremental process, using identical 423 equipment but with different configurations of the incremental CGN 424 devices in each region. Thus, IPv6 migration may be incrementally 425 achieved according to the real ISP and customer requirements. 427 4. Security Considerations 429 Security issues associated with NAT have been documented in [RFC2663] 430 and [RFC2993]. Security issues for large-scale address sharing, 431 including CGN, are discussed in [I-D.ietf-intarea-shared-addressing- 432 issues]. The present specification does not introduce any new 433 features to CGN itself, and hence no new security considerations. 434 Security issues for 6rd are documented in [RFC5569, RFC5969] and 435 those for DS-Lite in [I-D.ietf-softwire-dual-stack-lite]. 437 Since the tunnels proposed here exist entirely within a single ISP 438 network, between the HG/CPE and the CGN, the threat model is 439 relatively simple. [RFC4891] describes how to protect tunnels using 440 IPsec, but an ISP could reasonably deem its infrastructure to provide 441 adequate security without the additional protection and overhead of 442 IPsec. The intrinsic risks of tunnels are described in [I-D.ietf- 443 v6ops-tunnel-security-concerns], which recommends that tunneled 444 traffic should not cross border routers. The incremental CGN approach 445 respects this recommendation. To avoid other risks caused by tunnels, 446 it is important that any security mechanisms based on packet 447 inspection, and any implementation of ingress filtering, are applied 448 to IPv6 packets after they have been decapsulated by the CGN. The 449 dual-stack home gateway will need to provide basic security 450 functionality for IPv6 [I-D.ietf-v6ops-cpe-simple-security]. Other 451 aspects are described in [RFC4864]. 453 5. IANA Considerations 455 This draft does not request any IANA action. 457 6. Acknowledgements 459 Useful comments were made by Fred Baker, Dan Wing, Fred Templin, 460 Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair, 461 Shin Miyakawa, Joel Jaeggli, Jari Arkko, Tim Polk, Sean Turner and 462 other members of the IETF V6OPS working group. 464 7. Change Log [RFC Editor please remove] 466 draft-jiang-incremental-cgn-00, original version, 2009-02-27 468 draft-jiang-v6ops-incremental-cgn-00, revised after comments at 469 IETF74, 2009-04-23 471 draft-jiang-v6ops-incremental-cgn-01, revised after comments at v6ops 472 mailing list, 2009-06-30 474 draft-jiang-v6ops-incremental-cgn-02, remove normative parts (to be 475 documented in other WGs), 2009-07-06 477 draft-jiang-v6ops-incremental-cgn-03, revised after comments at v6ops 478 mailing list, 2009-09-24 480 draft-ietf-v6ops-incremental-cgn-00, accepted as v6ops wg document, 481 2009-11-17 483 draft-ietf-v6ops-incremental-cgn-01, revised after comments at v6ops 484 mailing list, 2010-06-21 486 draft-ietf-v6ops-incremental-cgn-02, revised after comments at v6ops 487 WGLC, 2010-10-11 489 draft-ietf-v6ops-incremental-cgn-03, revised according comments from 490 IESG, 2011-1-4 492 8. References 494 8.1. Normative References 496 [RFC2529] B. Carpenter, and C. Jung, "Transmission of IPv6 over IPv4 497 Domains without Explicit Tunnels", RFC2529, March 1999. 499 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina, 500 "Generic Routing Encapsulation (GRE)", RFC 2784, March 501 2000. 503 [RFC5569] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures 504 (6rd)", RFC 5569, January 2010. 506 [RFC5969] W. Townsley and O. Troan, "IPv6 via IPv4 Service Provider 507 Networks '6rd'", RFC5969, May 2010. 509 8.2. Informative References 511 [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address 512 Translator (NAT) Terminology and Considerations", RFC 2663, 513 August 1999. 515 [RFC2993] T. Hain, "Architectural Implications of NAT", RFC 2993, 516 November 2000. 518 [RFC3053] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6 519 Tunnel Broker", RFC 3053, January 2001. 521 [RFC3056] B. Carpenter and K. Moore, "Connection of IPv6 Domains via 522 IPv4 Clouds", RFC 3056, February 2001. 524 [RFC4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms 525 for IPv6 Hosts and Routers", RFC 4213, October 2005. 527 [RFC4798] J. De Clercq, D. Ooms, S. Prevost and F. Le Faucheur, 528 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 529 Edge Routers (6PE)", RFC 4798, February 2007. 531 [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter and E. 532 Klein, "Local Network Protection for IPv6", RFC 4864, May 533 2007. 535 [RFC4890] E. Davies and J. Mohacsi, "Recommendations for Filtering 536 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 538 [RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 539 RFC4891, May 2007. 541 [RFC5214] F. Templin, T. Gleeson and D. Thaler, "Intra-Site Automatic 542 Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. 544 [RFC5558] F. Templin, "Virtual Enterprise Traversal (VET)", RFC 5558, 545 February 2010. 547 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 548 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 549 2010. 551 [IPUSAGE] G. Huston, IPv4 Address Report, March 2009, 552 http://www.potaroo.net/tools/ipv4/index.html. 554 [I-D.ietf-softwire-dual-stack-lite] 555 A. Durand, "Dual-stack lite broadband deployments post IPv4 556 exhaustion", draft-ietf-softwire-dual-stack-lite, work in 557 progress. 559 [I-D.ietf-v6ops-ipv6-cpe-router] 560 H. Singh, W. Beebee, C. Donley, B. Stark and O. Troan, 561 "IPv6 CPE Router Recommendations", draft-ietf-v6ops-ipv6- 562 cpe-router, work in progress. 564 [I-D.ietf-v6ops-cpe-simple-security] 565 J. Woodyatt, "Recommended Simple Security Capabilities in 566 Customer Premises Equipment for Providing Residential IPv6 567 Internet Service", draft-ietf-v6ops-cpe-simple-security, 568 work in progress. 570 [I-D.ietf-behave-v6v4-xlate-stateful] 571 M. Bagnulo, P. Matthews and I. van Beijnum, "NAT64: Network 572 Address and Protocol Translation from IPv6 Clients to IPv4 573 Servers", draft-ietf-behave-v6v4-xlate-stateful, work in 574 progress. 576 [I-D.ietf-intarea-shared-addressing-issues] 577 M. Ford, et al, "Issues with IP Address Sharing", draft- 578 ietf-intarea-shared-addressing-issues, work in progress. 580 [I-D.nishitani-cgn] 581 I. Yamagata, T. Nishitani, S. Miyahawa, A. nakagawa and H. 582 Ashida, "Common requirements for IP address sharing 583 schemes", draft-nishitani-cgn, work in progress. 585 [I-D.arkko-ipv6-transition-guidelines] 586 Arkko, J. and F. Baker, "Guidelines for Using IPv6 587 Transition Mechanisms during IPv6 Deployment", draft-arkko- 588 ipv6-transition-guidelines, work in progress. 590 [I-D.ietf-behave-dns64] 591 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 592 "DNS64: DNS extensions for Network Address Translation from 593 IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64, 594 work in progress. 596 [I-D.ietf-behave-ftp64] 597 Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", 598 draft-ietf-behave-ftp64, work in progress. 600 [I-D.ietf-behave-v6v4-framework] 601 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 602 IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework, 603 work in progress. 605 [I-D.ietf-behave-v6v4-xlate] 606 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 607 Algorithm", draft-ietf-behave-v6v4-xlate, work in 608 progress. 610 Author's Addresses 612 Sheng Jiang 613 Huawei Technologies Co., Ltd 614 Huawei Building, No.3 Xinxi Rd., 615 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 616 P.R. China 617 Email: shengjiang@huawei.com 619 Dayong Guo 620 Huawei Technologies Co., Ltd 621 Huawei Building, No.3 Xinxi Rd., 622 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 623 P.R. China 624 Email: guoseu@huawei.com 626 Brian Carpenter 627 Department of Computer Science 628 University of Auckland 629 PB 92019 630 Auckland, 1142 631 New Zealand 632 Email: brian.e.carpenter@gmail.com