idnits 2.17.1 draft-jiang-v6ops-incremental-cgn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 24, 2009) is 5321 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: 2 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: March 22, 2010 B. Carpenter 5 University of Auckland 6 September 24, 2009 8 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 9 draft-jiang-v6ops-incremental-cgn-03.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on March 22, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Global IPv6 deployment was slower than originally expected in the 47 last ten years. As IPv4 address exhaustion gets closer, the IPv4/IPv6 48 transition issues become more critical and complicated. Host-based 49 transition mechanisms are not able to meet the requirements while 50 most end users are not sufficiently expert to configure or maintain 51 these transition mechanisms. Carrier Grade NAT with integrated 52 transition mechanisms can simplify the operation of end users during 53 the IPv4/IPv6 migration or coexistence period. This document proposes 54 an incremental Carrier-Grade NAT (CGN) approach for IPv6 transition. 55 It can provide IPv6 access services for IPv6-enabled end hosts and 56 IPv4 access services for IPv4 end hosts while remaining most of 57 legacy IPv4 ISP networks unchanged. It is suitable for the initial 58 stage of IPv4/IPv6 migration. Unlike CGN alone, it also supports and 59 encourages transition towards dual-stack or IPv6-only ISP networks. 61 Table of Contents 63 1. Introduction.................................................3 64 2. An Incremental CGN Approach..................................4 65 2.1. Incremental CGN Approach Overview.......................4 66 2.2. Choice of tunnelling technology.........................5 67 2.3. Behaviour of Dual-stack Home Gateway....................5 68 2.4. Behaviour of Dual-stack Carrier-Grade NAT...............6 69 2.5. Impact for existing end hosts and remaining networks....6 70 2.6. Discussion..............................................6 71 3. Migration towards IPv6 Core Network..........................7 72 3.1. Legacy communication in Phase 2.........................8 73 4. Security Considerations......................................8 74 5. IANA Considerations..........................................8 75 6. Acknowledgements.............................................9 76 7. Change Log...................................................9 77 8. References...................................................9 78 8.1. Normative References....................................9 79 8.2. Informative References..................................9 80 Author's Addresses.............................................11 82 1. Introduction 84 Up to now, global IPv6 deployment does not happen as was expected 10 85 years ago. The progress was much slower than originally expected. 86 Network providers were hesitant to take the first move while IPv4 was 87 and is still working well. However, IPv4 address exhaustion is now 88 confirmed to happen soon. The dynamically-updated IPv4 Address Report 89 [IPUSAGE] has analyzed this issue. It predicts early 2011 for IANA 90 unallocated address pool exhaustion and middle 2012 for RIR 91 unallocated address pool exhaustion. Based on this fact, the Internet 92 industry appears to have reached consensus that global IPv6 93 deployment is inevitable and has to be done quite quickly. 95 IPv4/IPv6 transition issues therefore become more critical and 96 complicated for the soon-coming global IPv6 deployment. Host-based 97 transition mechanisms alone are not able to meet the requirements in 98 all cases. Therefore, network supporting functions and/or new 99 transition mechanisms with simple user-side operation are needed. 101 Carried Grade NAT (CGN) alone creates operational problems, but does 102 nothing to help IPv4/IPv6 transition. In fact it allows ISPs to delay 103 the transition, and therefore causes double transition costs (once to 104 add CGN, and again to support IPv6). 106 Carrier-Grade NAT that integrates multiple transition mechanisms can 107 simplify the operation of end user services during the IPv4/IPv6 108 migration or coexistence period. CGNs are deployed on the network 109 side and managed/maintained by professionals. On the user side, new 110 CPE devices may be needed too. They may be provided by network 111 providers, depending on the specific business model. Dual-stack lite 112 [DSLite] is a CGN-based solution that supports transition, but it 113 requires the ISP to upgrade its network to IPv6 immediately. Many 114 ISPs hesitate to do this as the first step. Theoretically, DS-Lite 115 can be used with double encapsulation (IPv4-in-IPv6-in-IPv4) but this 116 seems even less likely to be accepted by an ISP and is not discussed 117 further. 119 This document proposes an incremental CGN approach for IPv6 120 transition. The approach is similar to DSLite, but the other way 121 around. Technically, it mainly combines v4-v4 NAT with v6-over-v4 122 tunnelling functions along with some minor adjustment. It can provide 123 IPv6 access services for IPv6-enabled end hosts and IPv4 access 124 services for IPv4 end hosts, while leaving most of legacy IPv4 ISP 125 networks unchanged. The deployment of this technology does not affect 126 legacy IPv4 hosts with global IPv4 addresses at all. It is suitable 127 for the initial stage of IPv4/IPv6 migration. It also supports 128 transition towards dual-stack or IPv6-only ISP networks. 130 2. An Incremental CGN Approach 132 Most ISP networks are still IPv4. Network providers are starting to 133 provide IPv6 access services for end users. However, at the initial 134 stage of IPv4/IPv6 migration, IPv4 connectivity and traffic would be 135 the majority for most ISP networks. ISPs would like to minimize the 136 changes on their IPv4 networks. Switching the whole ISP network into 137 IPv6-only would be considered as a radical strategy. Switching the 138 whole ISP network to dual stack is less radical, but introduces 139 operational costs and complications. Although some ISPs have 140 successfully deployed dual stack routers, others prefer not to do 141 this as their first step in IPv6. However, they currently face two 142 urgent pressures - to compensate for an immediate shortage of IPv4 143 addresses by deploying some method of address sharing, and to prepare 144 actively for the deployment of IPv6 address space and services. The 145 approach described in this draft addresses both of these pressures by 146 proceeding in two phases. 148 2.1. Incremental CGN Approach Overview 150 The incremental CGN approach we propose is illustrated as the 151 following figure. 153 +-------------+ 154 |IPv6 Internet| 155 +-------------+ 156 | 157 +-------------+----------+ 158 +-----+ +--+ | IPv4 ISP +--+--+ | +--------+ 159 |v4/v6|----|DS|=====+==========| CGN |-------+---| IPv4 | 160 |Host | |HG| | Network +-----+ | | |Internet| 161 +-----+ +--+ +--------------------+---+ +--------+ 162 _ _ _ _ _ _ _ _ _ _ _ | 163 ()_6_o_4_ _t_u_n_n_e_l_() +---------------------+ 164 | Existing IPv4 hosts | 165 +---------------------+ 167 Figure 1: Phase 1 of incremental CGN approach with IPv4 ISP network 169 DS HG = Dual-Stack Home Gateway (CPE). 171 The above figure shows only Phase 1, in which the ISP has not 172 significantly changed its IPv4 network. This approach enables IPv4 173 hosts to access the IPv4 Internet and IPv6 hosts to access the IPv6 174 Internet. A dual stack host can be treated as an IPv4 host when it 175 uses IPv4 access service and as an IPv6 host when it uses IPv6 access 176 service. In order to enable IPv4 hosts to access IPv6 Internet and 177 IPv6 hosts to access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its 178 replacement) can be integrated with CGN. The integration of such 179 mechanisms is out of scope for this document 181 Two new types of devices need to be deployed in this approach: a 182 dual-stack home gateway, which may follow the requirements of [6CPE], 183 and dual-stack Carrier-Grade NAT. The dual-stack home gateway 184 integrates IPv4 forwarding and v6-over-v4 tunnelling functions. It 185 may integrate v4-v4 NAT function, too. The dual-stack CGN integrates 186 v6-over-v4 tunnelling and carrier-grade v4-v4 NAT functions. 188 2.2. Choice of tunnelling technology 190 In principle, this model will work with any form of tunnel between 191 the DS HG and the dual-stack CGN. However, tunnels that require 192 individual configuration are clearly undesirable because of their 193 operational cost. Configured tunnels based directly on [RFC4213] are 194 therefore not suitable. A tunnel broker according to [RFC3053] would 195 also have high operational costs. 197 Modified 6RD [6RD] technology appears suitable to support v6-over-v4 198 tunnelling with low operational cost. Modified GRE [RFC2784] with 199 additional auto-configuration mechanism is also suitable to support 200 v6-over-v4 tunnelling. Other tunnelling mechanisms such as 6over4 201 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic Tunnel Addressing 202 Protocol (ISATAP) [RFC5214] or Virtual Enterprise Traversal (VET) 203 [VET] are also considered. If the ISP has an entirely MPLS 204 infrastructure between the CPE and the dual-stack CGN, it would also 205 be possible to consider a 6PE [RFC4798] tunnel directly over MPLS. 206 This would, however, only be suitable for an advanced CPE that is 207 unlikely to be found as a home gateway, and is not further discussed 208 here. 210 2.3. Behaviour of Dual-stack Home Gateway 212 When a dual-stack home gateway receives a data packet from an end 213 host, it firstly checks whether the packet is IPv4 or IPv6. For IPv4 214 data, the HG can directly forward it if there is no v4-v4 NAT running 215 on the HG. Or the HG translates packet source address from a HG-scope 216 private IPv4 address into a CGN-scope private IPv4 address. The HG 217 records the v4-v4 address mapping information for inbound packets, 218 just like normal NAT does. 220 For IPv6 data, the HG needs to encapsulate the data into an IPv4 221 tunnel, which has the dual-stack CGN as the other end. Then the HG 222 sends the new IPv4 packet towards CGN. 224 The HG records the mapping information between the tunnel and the 225 source IPv6 address for inbound packets if HG uplinks to more than 226 one CGN. Detailed considerations for the use of multiple CGNs by one 227 HG are for further study. 229 2.4. Behaviour of Dual-stack Carrier-Grade NAT 231 When a dual-stack CGN receives a data packet from a dual-stack home 232 gateway, it firstly checks whether the packet is a normal IPv4 packet 233 or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN 234 translates packet source address from a CGN-scope private IPv4 235 address into a public IPv4 address, and then send it to IPv4 Internet. 236 The CGN records the v4-v4 address mapping information for inbound 237 packets, just like normal NAT does. For a v6-over-v4 tunnel packet, 238 the CGN needs to decapsulate it into the original IPv6 packet and 239 then send it to IPv6 Internet. The CGN records the mapping 240 information between the tunnel and the source IPv6 address for 241 inbound packets. 243 Depending on the deployed location of the CGN, it may use v6-over-v4 244 tunnels to connect to the IPv6 Internet. 246 2.5. Impact for existing end hosts and remaining networks 248 This approach does not affect the remaining networks at all. Legacy 249 IPv4 ISP networks and their IPv4 devices remain in use. The existing 250 IPv4 hosts, shown as the right box in Figure 1, either having global 251 IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it 252 is now. Of course, these hosts, if they are upgraded to become dual- 253 stack hosts, can access IPv6 Internet through IPv4 ISP network by 254 using IPv6-over-IPv4 tunnel technologies. 256 2.6. Discussion 258 For IPv4 traffic, this approach inherits all the problems of CGN 259 (e.g., scaling, and the difficulty of supporting well-known ports for 260 inbound traffic). Application layer problems created by double NAT 261 are for further study. 263 If a different technology than v4-v4 NAT is chosen for IPv4 address 264 sharing, for example [APLUSP], the present approach could be suitably 265 modified, for example replacing the v4-v4 NAT function by the A+P 266 gateway function. 268 However, for IPv6 traffic, a user behind the DS HG will see normal 269 IPv6 service. We therefore observe that an IPv6 tunnel MTU of at 270 least 1500 bytes would ensure that the mechanism does not cause 271 excessive fragmentation of IPv6 traffic nor excessive IPv6 path MTU 272 discovery interactions. 274 However, for IPv6 traffic, a user behind the DS HG will see normal 275 IPv6 service. This, and the absence of NAT problems for IPv6, will 276 create an incentive for users and application service providers to 277 prefer IPv6. 279 ICMP filtering [RFC4890] function may be included as part of CGN 280 functions. 282 3. Migration towards IPv6 Core Network 284 If the core network transits to IPv6, this approach can easily be 285 transited into Phase 2, in which the ISP network is either dual-stack 286 or IPv6-only. 288 For dual-stack ISP networks, dual-stack home gateways can simply 289 switch off the v6-over-v4 function and forward both IPv6 and IPv4 290 traffic directly while the dual-stack CGN only keeps its v4-v4 NAT 291 function. However, this is considered an unlikely choice, since we 292 expect ISPs to choose the approach described here because they want 293 to avoid dual-stack deployment completely. 295 For IPv6-only ISP networks, the dual-stack lite solution [DSLite], 296 which also needs dual-stack home gateway and CGN devices, can be 297 adopted for Phase 2. The best business model for this approach is 298 that CPE has integrated the functions for both Phase 1 and 2, and can 299 automatically detect the change. For example, the DS HG can use the 300 appearance of IPv6 Route Advertisement messages or DHCPv6 messages as 301 a signal that Phase 2 has started. Then when ISPs decide to switch 302 from Phase 1 to Phase 2, it may be that only a configuration change 303 or a minor software update is needed on the CGNs. The DS HG will then 304 switch automatically to DSLite mode. The only impact on the home user 305 will be to receive a different IPv6 prefix. 307 It will not be necessary for all customers of a given ISP to switch 308 from Phase 1 to Phase 2 simultaneously; in fact it will be 309 operationally better to switch small groups of customers (e.g. all 310 those connected to a single point of presence). This is a matter of 311 planning and scheduling. 313 3.1. Legacy communication in Phase 2 315 We do not expect to see IPv6-only public services as long as there is 316 an IPv4-only customer base in the world, for obvious commercial 317 reasons. However, especially in Phase 2, IPv4/IPv6 intercommunication 318 may become issues. [DSLInter] describes a proposal to enhance DS-lite 319 solution with an additional feature to ease interconnection between 320 IPv4 and IPv6 realms. Furthermore, home users may encounter the 321 problem of reaching legacy IPv4-only public services from IPv6-only 322 clients. This problem could already exist in Phase 1, but will become 323 more serious as time goes on. Each ISP can provide its IPv6-only 324 customers with a network-layer translation service to satisfy this 325 need. Such a service is not fully defined at this time, so we refer 326 to it non-specifically as "NAT64". Current work in the IETF is 327 focussed on one particular proposal [NAT64]. 329 The NAT64 service can be provided as a common service located at the 330 border between the ISP and the IPv4 Internet, beyond the dual stack 331 CGN from the customer's viewpoint. It may be integrated into CGN 332 devices too. The question has been asked why it is better to do this 333 than to distribute the NAT64 function by locating it in (or near) the 334 home gateway, so that relevant translation state resides only in the 335 HG. While this might be suitable in Phase 1, when the ISP still 336 provides full IPv4 connectivity, it would force all translated 337 traffic into DSLite tunnels in Phase 2. This seems undesirable. 339 4. Security Considerations 341 Security issues associated with NAT have been documented in [RFC2663] 342 and [RFC2993]. 344 Further security analysis will be needed to understand double NAT 345 security issues and tunnel security issues. However, since the tunnel 346 proposed here exists entirely within a single ISP network, between 347 the CPE and the CGN, the threat model is relatively simple. [RFC4891] 348 describes how to protect tunnels using IPSec, but it is not clear 349 whether this would be an important requirement. An ISP could deem its 350 infrastructure to have sufficient security without additional 351 protection of the tunnels. 353 The dual-stack home gateway will need to provide basic security for 354 IPv6 [6CPESec]. Other aspects are described in [RFC4864]. 356 5. IANA Considerations 358 This draft does not request any IANA action. 360 6. Acknowledgements 362 Useful comments were made by Fred Baker, Dan Wing, Fred Templin, 363 Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair, 364 Shin Miyakawa and other members of the IETF V6OPS working group. 366 7. Change Log [RFC Editor please remove] 368 draft-jiang-incremental-cgn-00, original version, 2009-02-27 370 draft-jiang-v6ops-incremental-cgn-00, revised after comments at 371 IETF74, 2009-04-23 373 draft-jiang-v6ops-incremental-cgn-01, revised after comments at v6ops 374 mailing list, 2009-06-30 376 draft-jiang-v6ops-incremental-cgn-02, remove normative parts (to be 377 documented in other WGs), 2009-07-06 379 draft-jiang-v6ops-incremental-cgn-03, revised after comments at v6ops 380 mailing list, 2009-09-24 382 8. References 384 8.1. Normative References 386 [RFC2529] B. Carpenter, and C. Jung, "Transmission of IPv6 over IPv4 387 Domains without Explicit Tunnels", RFC2529, March 1999. 389 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina, 390 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 392 8.2. Informative References 394 [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address 395 Translator (NAT) Terminology and Considerations", RFC 2663, 396 August 1999. 398 [RFC2766] G. Tsirtsis and P. Srisuresh, "Network Address Translation 399 - Protocol Translation (NAT-PT)", RFC 2766, February 2000. 401 [RFC2993] T. Hain, "Architectural Implications of NAT", RFC 2993, 402 November 2000. 404 [RFC3053] A. Durand, P. Fasano, I. Guardini and D. Lento, "IPv6 405 Tunnel Broker", RFC 3053, January 2001. 407 [RFC3056] B. Carpenter and K. Moore, "Connection of IPv6 Domains via 408 IPv4 Clouds", RFC 3056, February 2001. 410 [RFC4213] E. Nordmark and R. Gilligan, "Basic Transition Mechanisms 411 for IPv6 Hosts and Routers", RFC 4213, October 2005. 413 [RFC4798] J. De Clercq, D. Ooms, S. Prevost and F. Le Faucheur, 414 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 415 Edge Routers (6PE)", RFC 4798, February 2007. 417 [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter and E. 418 Klein, "Local Network Protection for IPv6", RFC 4864, May 419 2007. 421 [RFC4890] E. Davies and J. Mohacsi, "Recommendations for Filtering 422 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 424 [RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 425 RFC4891, May 2007. 427 [RFC4966] C. Aoun and E. Davies, "Reasons to Move the Network Address 428 Translator - Protocol Translator (NAT-PT) to Historic 429 Status", RFC 4966, July 2007. 431 [RFC5214] F. Templin, T. Gleeson and D. Thaler, "Intra-Site Automatic 432 Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. 434 [DSLite] A. Durand, R. Droms, B. Haberman and J. Woodyatt, "Dual- 435 stack lite broadband deployments post IPv4 exhaustion", 436 draft-durand-softwire-dual-stack-lite-01, work in progress. 438 [IPUSAGE] G. Huston, IPv4 Address Report, March 2009, 439 http://www.potaroo.net/tools/ipv4/index.html. 441 [6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures 442 (6rd)", draft-despres-6rd, work in progress. 444 [6CPE] H. Singh, "IPv6 CPE Router Recommendations", draft-wbeebee- 445 ipv6-cpe-router, work in progress. 447 [6CPESec] J. Woodyatt, "Recommended Simple Security Capabilities in 448 Customer Premises Equipment for Providing Residential IPv6 449 Internet Service", draft-ietf-v6ops-cpe-simple-security, 450 work in progress. 452 [APLUSP] R. Bush, O. Maennel, J. Zorz, S. Bellovin and L. Cittadini, 453 "The A+P Approach to the IPv4 Address Shortage", draft- 454 ymbk-aplusp, work in progress. 456 [VET] F. Templin, "Virtual Enterprise Traversal (VET)", draft- 457 templin-autoconf-dhcp, work in progress. 459 [DSLInter] M. Boucadair, et al, "Stateless IPv4-IPv6 Interconnection 460 in the Context of DS-lite Deployment", draft-boucadair- 461 dslite-interco-v4v6, work in progress. 463 [NAT64] M. Bagnulo, P. Matthews and I. van Beijnum, "NAT64: Network 464 Address and Protocol Translation from IPv6 Clients to IPv4 465 Servers", draft-bagnulo-behave-nat64, work in progress. 467 Author's Addresses 469 Sheng Jiang 470 Huawei Technologies Co., Ltd 471 KuiKe Building, No.9 Xinxi Rd., 472 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 473 P.R. China 474 Phone: 86-10-82836774 475 Email: shengjiang@huawei.com 477 Dayong Guo 478 Huawei Technologies Co., Ltd 479 KuiKe Building, No.9 Xinxi Rd., 480 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 481 P.R. China 482 Phone: 86-10-82836284 483 Email: guoseu@huawei.com 485 Brian Carpenter 486 Department of Computer Science 487 University of Auckland 488 PB 92019 489 Auckland, 1142 490 New Zealand 491 Email: brian.e.carpenter@gmail.com