idnits 2.17.1 draft-jiang-v6ops-incremental-cgn-00.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 8, 2009) is 5465 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) == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 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: November 6, 2009 B. Carpenter 5 University of Auckland 6 May 8, 2009 8 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 9 draft-jiang-v6ops-incremental-cgn-00.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 November 10, 2009. 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) solution 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. Terminology.................................................4 65 3. An Incremental CGN Solution..................................4 66 3.1. Incremental CGN Solution Overview.......................4 67 3.2. Choice of tunnelling technology.........................5 68 3.3. Behaviour of Dual-stack Home Gateway....................6 69 3.4. Behaviour of Dual-stack Carrier-Grade NAT...............6 70 3.5. Impact for end hosts and remaining networks.............7 71 3.6. Discussion.............................................7 72 4. Migration towards IPv6 Core Network..........................7 73 4.1. Legacy communication in Phase 2.........................8 74 5. Security Considerations......................................8 75 6. IANA Considerations.........................................9 76 7. Acknowledgements............................................9 77 8. Change Log [RFC Editor please remove]........................9 78 9. References..................................................9 79 9.1. Normative References....................................9 80 9.2. Informative References..................................9 81 Author's Addresses............................................11 83 1. Introduction 85 Up to now, global IPv6 deployment does not happen as was expected 10 86 years ago. The progress was much slower than originally expected. 87 Network providers were hesitant to take the first move while IPv4 was 88 and is still working well. However, IPv4 address exhaustion is now 89 confirmed to happen soon. The dynamically-updated IPv4 Address Report 90 [IPUSAGE] has analyzed this issue. It predicts early 2011 for IANA 91 unallocated address pool exhaustion and middle 2012 for RIR 92 unallocated address pool exhaustion. Based on this fact, the Internet 93 industry appears to have reached consensus that global IPv6 94 deployment is inevitable and has to be done quite quickly. 96 IPv4/IPv6 transition issues therefore become more critical and 97 complicated for the soon-coming global IPv6 deployment. Host-based 98 transition mechanisms alone are not able to meet the requirements. 99 They are too complicated for most end users who do not have enough 100 technical knowledge to configure or maintain these transition 101 mechanisms. New transition mechanisms with simple user-side operation 102 are needed. 104 Carried Grade NAT (CGN) alone creates operational problems, but does 105 nothing to help IPv4/IPv6 transition. In fact it allows ISPs to delay 106 the transition, and therefore causes double transition costs (once to 107 add CGN, and again to support IPv6). 109 Carrier-Grade NAT that integrates multiple transition mechanisms can 110 simplify the operation of end user services during the IPv4/IPv6 111 migration or coexistence period. CGNs are deployed on the network 112 side and managed/maintained by professionals. On the user side, new 113 CPE devices may be needed too. They may be provided by network 114 providers, depending on the specific business model. Dual-stack lite 115 [DSLite] is a CGN-based solution that supports transition, but it 116 requires the ISP to upgrade its network to IPv6 immediately. Many 117 ISPs hesitate to do this as the first step. 119 This document proposes an incremental CGN solution for IPv6 120 transition. The solution 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 solution 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. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 3. An Incremental CGN Solution 138 Most ISP networks are still IPv4. Network providers are starting to 139 provide IPv6 access services for end users. However, at the initial 140 stage of IPv4/IPv6 migration, IPv4 connectivity and traffic would be 141 the majority for most ISP networks. ISPs would like to minimize the 142 changes on their IPv4 networks. Switching the whole ISP network into 143 IPv6-only would be considered as a radical strategy. Switching the 144 whole ISP network to dual stack is less radical, but introduces 145 operational costs and complications. Although some ISPs have 146 successfully deployed dual stack routers, others prefer not to do 147 this as their first step in IPv6. However, they currently face two 148 urgent pressures - to compensate for an immediate shortage of IPv4 149 addresses by deploying some method of address sharing, and to prepare 150 actively for the deployment of IPv6 address space and services. The 151 solution described in this draft addresses both of these pressures by 152 proceeding in two phases. 154 3.1. Incremental CGN Solution Overview 156 The incremental CGN solution we propose is illustrated as the 157 following figure. 159 +-------------+ 160 |IPv6 Internet| 161 +-------------+ 162 | 163 +-------------+----------+ 164 +-----+ +--+ | IPv4 ISP +--+--+ | +--------+ 165 |v4/v6|----|DS|=====+==========| CGN |-------+---| IPv4 | 166 |Host | |HG| | Network +-----+ | | |Internet| 167 +-----+ +--+ +--------------------+---+ +--------+ 168 _ _ _ _ _ _ _ _ _ _ _ | 169 ()_6_o_4_ _t_u_n_n_e_l_() +---------------------+ 170 | Existing IPv4 hosts | 171 +---------------------+ 173 Figure 1: Phase 1 of incremental CGN solution with IPv4 ISP network 175 DS HG = Dual-Stack Home Gateway (CPE). 177 The above figure shows only Phase 1, in which the ISP has not 178 significantly changed its IPv4 network. This solution enables IPv4 179 hosts to access the IPv4 Internet and IPv6 hosts to access the IPv6 180 Internet. A dual stack host can be treated as an IPv4 host when it 181 uses IPv4 access service and as an IPv6 host when it uses IPv6 access 182 service. In order to enable IPv4 hosts to access IPv6 Internet and 183 IPv6 hosts to access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its 184 replacement) can be integrated with CGN. The integration of NAT-PT is 185 out of scope for this document 187 Two new types of devices need to be deployed in this solution: a 188 dual-stack home gateway, which may follow the requirements of [6CPE], 189 and dual-stack Carrier-Grade NAT. The dual-stack home gateway 190 integrates IPv4 forwarding and v6-over-v4 tunnelling functions. It 191 may integrate v4-v4 NAT function, too. The dual-stack CGN integrates 192 v6-over-v4 tunnelling and carrier-grade v4-v4 NAT functions. 194 3.2. Choice of tunnelling technology 196 In principle, this model will work with any form of tunnel between 197 the DS HG and the dual-stack CGN. However, tunnels that require 198 individual configuration are clearly undesirable because of their 199 operational cost. Configured tunnels based directly on [RFC4213] are 200 therefore not suitable. A tunnel broker according to [RFC3053] would 201 also have high operational costs. 203 Modified 6RD [6RD] technology appears suitable to support v6-over-v4 204 tunnelling with low operational cost. 6RD was designed for an IPv4 205 ISP scenario and allows re-use of slightly modified existing support 206 for 6to4 [RFC3056]. 6RD using a 32-bit IPv6 prefix from the ISP's 207 address space will allow each CPE to receive a 64-bit prefix 208 corresponding to its IPv4 address. If it is desired to delegate 56- 209 bit prefixes to each customer, the 6RD prefix must be of 24 bits, as 210 illustrated below. In that case, the ISP must have a general IPv6 211 prefix shorter than /24. 213 +----------------------.------------------------------+ 214 | 6RD-relay IPv6 prefix| IPv4 address | 215 | of the ISP | of the customer site | 216 +----------------------'------------------------------+ 217 <----- 24 bits -----><--------- 32 bits ----------> 219 Figure 2: format of a 56-bit 6RD prefix 221 Modified GRE [RFC2784] with additional auto-configuration mechanism 222 is also suitable to support v6-over-v4 tunnelling. 224 Other tunnelling mechanisms such as ISATAP [RFC5214] or VET [VET] 225 could also be considered, but 6RD seems well adapted. 227 If the ISP has an entirely MPLS infrastructure between the CPE and 228 the dual-stack CGN, it would also be possible to consider a 6PE 229 [RFC4798] tunnel directly over MPLS. This would, however, only be 230 suitable for an advanced CPE that is unlikely to be found as a home 231 gateway, and is not further discussed here. 233 3.3. Behaviour of Dual-stack Home Gateway 235 When a dual-stack home gateway receives a data packet from an end 236 host, it firstly checks whether the packet is IPv4 or IPv6. For IPv4 237 data, the HG can directly forward it if there is no v4-v4 NAT running 238 on the HG. Or the HG translates packet source address from a HG-scope 239 private IPv4 address into a CGN-scope private IPv4 address. The HG 240 should record the v4-v4 address mapping information for inbound 241 packets, just like normal NAT does. 243 For IPv6 data, the HG needs to encapsulate the data into an IPv4 244 tunnel, which has the dual-stack CGN as the other end. Then the HG 245 sends the new IPv4 packet towards CGN. 247 The HG should record the mapping information between the tunnel and 248 the source IPv6 address for inbound packets if HG uplinks to more 249 than one CGN. Detailed considerations for the use of multiple CGNs by 250 one HG are for further study. 252 3.4. Behaviour of Dual-stack Carrier-Grade NAT 254 When a dual-stack CGN receives a data packet from a dual-stack home 255 gateway, it firstly checks whether the packet is a normal IPv4 packet 256 or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN 257 translates packet source address from a CGN-scope private IPv4 258 address into a public IPv4 address, and then send it to IPv4 Internet. 259 The CGN should record the v4-v4 address mapping information for 260 inbound packets, just like normal NAT does. For a v6-over-v4 tunnel 261 packet, the CGN needs to decapsulate it into the original IPv6 packet 262 and then send it to IPv6 Internet. The CGN should record the mapping 263 information between the tunnel and the source IPv6 address for 264 inbound packets. 266 Depending on the deployed location of the CGN, it may use v6-over-v4 267 tunnels to connect to the IPv6 Internet. 269 3.5. Impact for end hosts and remaining networks 271 This solution does not affect the remaining networks at all. Legacy 272 IPv4 ISP networks and their IPv4 devices remain in use. The existing 273 IPv4 hosts, shown as the right box in Figure 1, either having global 274 IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it 275 is now. Of course, these hosts can access IPv6 Internet through IPv4 276 ISP network by using IPv4-over-IPv6 tunnel technologies. 278 3.6. Discussion 280 It should be noted that for IPv4 traffic, this solution inherits all 281 the problems of CGN (e.g., scaling, and the difficulty of supporting 282 well-known ports for inbound traffic). Application layer problems 283 created by double NAT are for further study. 285 If a different solution than v4-v4 NAT is chosen for IPv4 address 286 sharing, for example [APLUSP], the present solution could be suitably 287 modified, for example replacing the v4-v4 NAT function by the A+P 288 gateway function. 290 However, for IPv6 traffic, a user behind the DS HG will see normal 291 IPv6 service. It is strongly recommended that all IPv6 tunnels 292 support an MTU of at least 1500 bytes, to ensure that the mechanism 293 usually does not cause fragmentation of IPv6 traffic. This, and the 294 absence of NAT problems for IPv6, will create an incentive for users 295 and application service providers to prefer IPv6. 297 4. Migration towards IPv6 Core Network 299 When the core network starts transition to IPv6, this solution can 300 easily be transited into Phase 2, in which the ISP network is either 301 dual-stack or IPv6-only. 303 For dual-stack ISP networks, dual-stack home gateways can simply 304 switch off the v6-over-v4 function and forward both IPv6 and IPv4 305 traffic directly; the dual-stack CGN should only keep its v4-v4 NAT 306 function. However, this is considered an unlikely choice, since we 307 expect ISPs to choose the approach described here because they want 308 to avoid dual-stack deployment completely. 310 For IPv6-only ISP networks, the dual-stack lite solution [DSLite], 311 which also needs dual-stack home gateway and CGN devices, can be 312 adopted for Phase 2. The best business model for this solution is 313 that CPE has integrated the functions for both Phase 1 and 2, and can 314 automatically detect the change. For example, the DS HG can use the 315 appearance of IPv6 Route Advertisement messages or DHCPv6 messages as 316 a signal that Phase 2 has started. Then when ISPs decide to switch 317 from Phase 1 to Phase 2, it may be that only a configuration change 318 or a minor software update is needed on the CGNs. The DS HG will then 319 switch automatically to DSLite mode. The only impact on the home user 320 will be to receive a different IPv6 prefix. 322 Note that if the 6RD mechanism is used in Phase 1, the user may have 323 a /64 prefix during Phase 1, but could get a shorter prefix such as 324 /56 in Phase 2. This would be an improved service offering available 325 as a result of the Phase 1 to Phase 2 transition. 327 It will not be necessary for all customers of a given ISP to switch 328 from Phase 1 to Phase 2 simultaneously; in fact it will be 329 operationally better to switch small groups of customers (e.g. all 330 those connected to a single point of presence). This is a matter of 331 planning and scheduling. 333 4.1. Legacy communication in Phase 2 335 We do not expect to see IPv6-only public services as long as there is 336 an IPv4-only customer base in the world, for obvious commercial 337 reasons. However, especially in Phase 2, home users may encounter the 338 problem of reaching legacy IPv4-only public services from IPv6-only 339 clients. This problem could already exist in Phase 1, but will become 340 more serious as time goes on. It is proposed that each ISP should 341 provide its IPv6-only customers with a network-layer translation 342 service to satisfy this need. Such a service is not fully defined at 343 this time, so we refer to it non-specifically as NAT64. 345 We propose that the NAT64 service should be provided as a common 346 service located at the border between the ISP and the IPv4 Internet, 347 beyond the dual stack CGN from the customer's viewpoint. It may be 348 integrated into CGN devices too. The question has been asked why it 349 is better to do this than to distribute the NAT64 function by 350 locating it in (or near) the home gateway, so that relevant 351 translation state resides only in the HG. While this might be 352 suitable in Phase 1, when the ISP still provides full IPv4 353 connectivity, it would force all translated traffic into DS-Lite 354 tunnels in Phase 2. This seems undesirable. 356 5. Security Considerations 358 Security issues associated with NAT have been documented in [RFC2663] 359 and [RFC2993]. 361 Further security analysis will be needed to understand double NAT 362 security issues and tunnel security issues. However, since the tunnel 363 proposed here exists entirely within a single ISP network, between 364 the CPE and the CGN, the threat model is relatively simple. [RFC4891] 365 describes how to protect tunnels using IPSec, but it is not clear 366 whether this would be an important requirement. An ISP could deem its 367 infrastructure to have sufficient security without additional 368 protection of the tunnels. 370 The dual-stack home gateway will need to provide basic security for 371 IPv6 [6CPESec]. Other aspects are described in [RFC4864]. 373 6. IANA Considerations 375 This draft does not request any IANA action. 377 7. Acknowledgements 379 Shin Miyakawa discussed a related proposal at IETF72. 381 Useful comments were made by Fred Templin, and other members of the 382 IETF V6OPS working group. 384 8. Change Log [RFC Editor please remove] 386 draft-jiang-incremental-cgn-00, original version, 2009-02-27 388 draft-jiang-v6ops-incremental-cgn-00, revised after comments at 389 IETF74, 2009-04-23 391 9. References 393 9.1. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, 399 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 401 9.2. Informative References 403 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 404 Translator (NAT) Terminology and Considerations", RFC 2663, 405 August 1999. 407 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation 408 - Protocol Translation (NAT-PT)", RFC 2766, February 2000. 410 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 411 November 2000. 413 [RFC3053] A. Durand, P. Fasano, I. Guardini, D. Lento, "IPv6 Tunnel 414 Broker", RFC3053, January 2001. 416 [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 417 IPv4 Clouds", RFC3056, February 2001. 419 [RFC4213] E. Nordmark, R. Gilligan, "Basic Transition Mechanisms for 420 IPv6 Hosts and Routers", RFC4213, October 2005. 422 [RFC4798] J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur, 423 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider 424 Edge Routers (6PE)", RFC4798, February 2007. 426 [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein, 427 "Local Network Protection for IPv6", RFC4864, May 2007. 429 [RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 430 RFC4891, May 2007. 432 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 433 Address Translator - Protocol Translator (NAT-PT) to 434 Historic Status", RFC 4966, July 2007. 436 [RFC5214] F. Templin, T. Gleeson, and D. Thaler, "Intra-Site 437 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 438 March 2008. 440 [DSLite] A. Durand, R. Droms, B. Haberman, J. Woodyatt, "Dual-stack 441 lite broadband deployments post IPv4 exhaustion", draft- 442 durand-softwire-dual-stack-lite-01, work in progress. 444 [IPUSAGE] Huston, G., IPv4 Address Report, March 2009, 445 http://www.potaroo.net/tools/ipv4/index.html. 447 [6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures 448 (6rd)", draft-despres-6rd-03, work in progress. 450 [6CPE] H. Singh, "IPv6 CPE Router Recommendations", draft-wbeebee- 451 ipv6-cpe-router-04, work in progress. 453 [6CPESec] J. Woodyatt, "Recommended Simple Security Capabilities in 454 Customer Premises Equipment for Providing Residential IPv6 455 Internet Service", draft-ietf-v6ops-cpe-simple-security-05, 456 work in progress. 458 [APLUSP] R. Bush, O. Maennel, J. Zorz, S. Bellovin, L. Cittadini, 459 "The A+P Approach to the IPv4 Address Shortage", draft- 460 ymbk-aplusp, work in progress. 462 [VET] F. Templin, "Virtual Enterprise Traversal (VET)", draft- 463 templin-autoconf-dhcp, work in progress. 465 Author's Addresses 467 Sheng Jiang 468 Huawei Technologies Co., Ltd 469 KuiKe Building, No.9 Xinxi Rd., 470 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 471 P.R. China 472 Phone: 86-10-82836774 473 Email: shengjiang@huawei.com 475 Dayong Guo 476 Huawei Technologies Co., Ltd 477 KuiKe Building, No.9 Xinxi Rd., 478 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 479 P.R. China 480 Phone: 86-10-82836284 481 Email: guoseu@huawei.com 483 Brian Carpenter 484 Department of Computer Science 485 University of Auckland 486 PB 92019 487 Auckland, 1142 488 New Zealand 489 Email: brian.e.carpenter@gmail.com