idnits 2.17.00 (12 Aug 2021) /tmp/idnits10886/draft-jiang-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 2 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 (March 1, 2009) is 4822 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: draft-despres-6rd has been published as RFC 5569 == Outdated reference: A later version (-04) exists of draft-wbeebee-ipv6-cpe-router-03 == Outdated reference: draft-ietf-v6ops-cpe-simple-security has been published as RFC 6092 Summary: 2 errors (**), 0 flaws (~~), 5 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: August 29, 2009 B. Carpenter 5 University of Auckland 6 March 1, 2009 8 An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition 9 draft-jiang-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 August 29, 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. Behaviour of Dual-stack Home Gateway....................5 68 3.3. Behaviour of Dual-stack Carrier-Grade NAT...............5 69 3.4. Impact for end hosts and remaining networks.............6 70 4. Migration towards IPv6 Core Network..........................6 71 5. Security Considerations......................................6 72 6. IANA Considerations.........................................7 73 7. References..................................................7 74 7.1. Normative References....................................7 75 7.2. Informative References..................................7 76 Author's Addresses.............................................9 78 1. Introduction 80 Up to now, global IPv6 deployment does not happen as was expected 10 81 years ago. The progress was much slower than originally expected. 82 Network providers were hesitant to take the first move while IPv4 was 83 and is still working well. However, IPv4 address exhaustion is now 84 confirmed to happen soon. The dynamically-updated IPv4 Address Report 85 [IPUSAGE] has analyzed this issue. It predicts early 2011 for IANA 86 unallocated address pool exhaustion and middle 2012 for RIR 87 unallocated address pool exhaustion. Based on this fact, the Internet 88 industry appears to have reached consensus that global IPv6 89 deployment is inevitable and has to be done quite quickly. 91 IPv4/IPv6 transition issues therefore become more critical and 92 complicated for the soon-coming global IPv6 deployment. Host-based 93 transition mechanisms alone are not able to meet the requirements. 94 They are too complicated for most end users who do not have enough 95 technical knowledge to configure or maintain these transition 96 mechanisms. New transition mechanisms with simple user-side operation 97 are needed. 99 Carried Grade NAT (CGN) alone creates operational problems, but does 100 nothing to help IPv4/IPv6 transition. In fact it allows ISPs to delay 101 the transition, and therefore causes double transition costs (once to 102 add CGN, and again to support IPv6). 104 Carrier-Grade NAT that integrates multiple transition mechanisms can 105 simplify the operation of end user services during the IPv4/IPv6 106 migration or coexistence period. CGNs are deployed on the network 107 side and managed/maintained by professionals. On the user side, new 108 CPE devices may be needed too. They may be provided by network 109 providers, depending on the specific business model. Dual-stack lite 110 [DSLite] is a CGN-based solution that supports transition, but it 111 requires the ISP to upgrade its network to IPv6 immediately. Many 112 ISPs hesitate to do this as the first step. 114 This document proposes an incremental CGN solution for IPv6 115 transition. The solution is similar to DSLite, but the other way 116 around. Technically, it mainly combines v4-v4 NAT with v6-over-v4 117 tunnelling functions along with some minor adjustment. It can provide 118 IPv6 access services for IPv6-enabled end hosts and IPv4 access 119 services for IPv4 end hosts, while leaving most of legacy IPv4 ISP 120 networks unchanged. The deployment of this solution does not affect 121 legacy IPv4 hosts with global IPv4 addresses at all. It is suitable 122 for the initial stage of IPv4/IPv6 migration. It also supports 123 transition towards dual-stack or IPv6-only ISP networks. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 3. An Incremental CGN Solution 133 Most ISP networks are still IPv4. Network providers are starting to 134 provide IPv6 access services for end users. However, at the initial 135 stage of IPv4/IPv6 migration, IPv4 connectivity and traffic would be 136 the majority for ISP networks. ISPs would like to minimize the 137 changes on their IPv4 networks. Switching the whole ISP network into 138 IPv6-only would be considered as a radical strategy. Switching the 139 whole ISP network to dual stack is less radical, but introduces 140 operational costs and complications. 142 3.1. Incremental CGN Solution Overview 144 The incremental CGN solution we propose is illustrated as the 145 following figure. 147 +-------------+ 148 |IPv6 Internet| 149 +-------------+ 150 | 151 +-----+ +--+ +-------+ +-----+ +--------+ 152 |v4/v6|----|DS|----| IPv4 |----| CGN |---------| IPv4 | 153 |Host | |HG| |Network| | | | |Internet| 154 +-----+ +--+ +-------+ +-----+ | +--------+ 155 _ _ _ _ _ _ _ _ _ _ _ +---------------------+ 156 ()_6_o_4_ _t_u_n_n_e_l_() | Existing IPv4 hosts | 157 +---------------------+ 159 Figure 1: Phase 1 of incremental CGN solution with IPv4 ISP network 161 DS HG = Dual-Stack Home Gateway. 163 The above figure shows only Phase 1, in which the ISP has not 164 significantly changed its IPv4 network. This solution enables IPv4 165 hosts to access the IPv4 Internet and IPv6 hosts to access the IPv6 166 Internet. A dual stack host can be treated as an IPv4 host when it 167 uses IPv4 access service and as an IPv6 host when it uses IPv6 access 168 service. In order to enable IPv4 hosts to access IPv6 Internet and 169 IPv6 hosts to access IPv4 Internet, NAT-PT [RFC2766, RFC4966] (or its 170 replacement) can be integrated with CGN. The integration of NAT-PT is 171 out of scope for this document 172 Two new types of devices need to be deployed in this solution: a 173 dual-stack home gateway, which may follow the requirements of [6CPE], 174 and dual-stack Carrier-Grade NAT. The dual-stack home gateway 175 integrates IPv4 forwarding and v6-over-v4 tunnelling functions. It 176 may integrate v4-v4 NAT function, too. The dual-stack CGN integrates 177 v6-over-v4 tunnelling and carrier-grade v4-v4 NAT functions. Modified 178 6RD [6RD] technology may be used to support v6-over-v4 tunnelling. 179 Other tunnelling mechanisms such as ISATAP [RFC5214] could also be 180 considered, but 6RD appears to fit well and allows re-use of existing 181 support for 6to4 [RFC3056]. 183 3.2. Behaviour of Dual-stack Home Gateway 185 When a dual-stack home gateway receives a data packet from an end 186 host, it firstly checks whether the packet is IPv4 or IPv6. For IPv4 187 data, the HG can directly forward it if there is no v4-v4 NAT running 188 on the HG. Or the HG translates packet source address from a HG-scope 189 private IPv4 address into a CGN-scope private IPv4 address. The HG 190 should record the v4-v4 address mapping information for inbound 191 packets, just like normal NAT does. 193 For IPv6 data, the HG needs to encapsulate the data into an IPv4 194 tunnel, which sets the dual-stack CGN as another end. Then the HG 195 sends the new IPv4 packet towards CGN. 197 The HG should record the mapping information between the tunnel and 198 the source IPv6 address for inbound packets if HG uplinks to more 199 than one CGN. Detailed considerations for the use of multiple CGNs by 200 one HG are for further study. 202 3.3. Behaviour of Dual-stack Carrier-Grade NAT 204 When a dual-stack CGN receives a data packet from a dual-stack home 205 gateway, it firstly checks whether the packet is a normal IPv4 packet 206 or a v6-over-v4 tunnel packet. For a normal IPv4 packet, the CGN 207 translates packet source address from a CGN-scope private IPv4 208 address into a public IPv4 address, and then send it to IPv4 Internet. 209 The CGN should record the v4-v4 address mapping information for 210 inbound packets, just like normal NAT does. For a v6-over-v4 tunnel 211 packet, the CGN needs to decapsulate it into the original IPv6 packet 212 and then send it to IPv6 Internet. The CGN should record the mapping 213 information between the tunnel and the source IPv6 address for 214 inbound packets. 216 Depending on the deployed location of the CGN, it may use v6-over-v4 217 tunnels to connect to the IPv6 Internet. 219 3.4. Impact for end hosts and remaining networks 221 This solution does not affect the remaining networks at all. Legacy 222 IPv4 ISP networks and their IPv4 devices remain in use. The existing 223 IPv4 hosts, shown as the right box in Figure 1, either having global 224 IPv4 addresses or behind v4-v4 NAT can connect to IPv4 Internet as it 225 is now. 227 3.5. Discussion 229 It should be noted that for IPv4 traffic, this solution inherits all 230 the problems of CGN (e.g., scaling, and the difficulty of supporting 231 well-known ports for inbound traffic). Application layer problems 232 created by double NAT are for further study. 234 However, for IPv6 traffic, a user behind the DS HG will see normal 235 IPv6 service. It is strongly recommended that all IPv6 tunnels 236 support a large MTU, at least 1500 bytes, to avoid fragmentation 237 problems. This, and the absence of NAT problems for IPv6, will create 238 an incentive for users and application service providers to prefer 239 IPv6. 241 4. Migration towards IPv6 Core Network 243 When the core network starts transition to IPv6, this solution can 244 easily be transited into Phase 2, in which the ISP network is either 245 dual-stack or IPv6-only. For dual-stack ISP networks, dual-stack home 246 gateways can simply switch off the v6-over-v4 function and forward 247 both IPv6 and IPv4 traffic directly; dual-stack CGN should only keep 248 v4-v4 NAT function. For IPv6-only ISP networks, the dual-stack lite 249 solution, which also has dual-stack home gateway and CGN devices, can 250 be adopted for Phase 2. The best business model for this solution is 251 that CPE has integrated the functions for both Phase 1 and 2, and can 252 automatically detect the change. Then when ISPs decide to switch from 253 Phase 1 to Phase 2, it may be that only a configuration change or a 254 minor software update is needed on the CGNs. The DS HG will then 255 switch automatically to basic dual stack or DSLite mode. The only 256 impact on the home user will be to receive a different IPv6 prefix. 257 Note that if the 6RD mechanism is used in Phase 1, the user will most 258 likely have a /64 prefix during Phase 1, but could get a shorter 259 prefix such as /56 in Phase 2. This would be an improved service 260 offering available as a result of the Phase 1 to Phase 2 transition. 262 5. Security Considerations 264 Security issues associated with NAT have been documented in [RFC2663] 265 and [RFC2993]. 267 Further security analysis will be needed to understand double NAT 268 security issues and tunnel security issues. However, since the tunnel 269 exists entirely in a single ISP network, between the CPE and the CGN, 270 the threat model is relatively simple. [RFC4891] describes how to 271 protect tunnels using IPSec, but it is not clear whether this would 272 be an important requirement. 274 The dual-stack home gateway will need to provide basic security for 275 IPv6 [6CPESec]. Other aspects are described in [RFC4864]. 277 6. IANA Considerations 279 This draft does not request any IANA action. 281 7. References 283 7.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 7.2. Informative References 290 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 291 Translator (NAT) Terminology and Considerations", RFC 2663, 292 August 1999. 294 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation 295 - Protocol Translation (NAT-PT)", RFC 2766, February 2000. 297 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 298 November 2000. 300 [RFC3056] B. Carpenter, K. Moore, "Connection of IPv6 Domains via 301 IPv4 Clouds", RFC3056, February 2001. 303 [RFC4864] G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein, 304 "Local Network Protection for IPv6", RFC4864, May 2007. 306 [RFC4891] R. Graveman, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 307 RFC4891, May 2007. 309 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 310 Address Translator - Protocol Translator (NAT-PT) to 311 Historic Status", RFC 4966, July 2007. 313 [RFC5214] F. Templin, T. Gleeson, and D. Thaler, "Intra-Site 314 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 315 March 2008. 317 [DSLite] A. Durand, R. Droms, B. Haberman, J. Woodyatt, "Dual-stack 318 lite broadband deployments post IPv4 exhaustion", draft- 319 durand-softwire-dual-stack-lite-01, work in progress. 321 [IPUSAGE] Huston, G., IPv4 Address Report, March 2009, 322 http://www.potaroo.net/tools/ipv4/index.html. 324 [6RD] R. Despres, "IPv6 Rapid Deployment on IPv4 infrastructures 325 (6rd)", draft-despres-6rd-02, work in progress. 327 [6CPE] H. Singh, "IPv6 CPE Router Recommendations", draft-wbeebee- 328 ipv6-cpe-router-03, work in progress. 330 [6CPESec] J. Woodyatt, "Recommended Simple Security Capabilities in 331 Customer Premises Equipment for Providing Residential IPv6 332 Internet Service", draft-ietf-v6ops-cpe-simple-security-03, 333 work in progress. 335 Author's Addresses 337 Sheng Jiang 338 Huawei Technologies Co., Ltd 339 KuiKe Building, No.9 Xinxi Rd., 340 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 341 P.R. China 342 Phone: 86-10-82836774 343 Email: shengjiang@huawei.com 345 Dayong Guo 346 Huawei Technologies Co., Ltd 347 KuiKe Building, No.9 Xinxi Rd., 348 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 349 P.R. China 350 Phone: 86-10-82836284 351 Email: guoseu@huawei.com 353 Brian Carpenter 354 Department of Computer Science 355 University of Auckland 356 PB 92019 357 Auckland, 1142 358 New Zealand 359 Email: brian.e.carpenter@gmail.com