idnits 2.17.1 draft-shirasaki-nat444-02.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 5030 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.shirasaki-isp-shared-addr' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'I-D.shirasaki-nat444-isp-shared-addr' is defined on line 271, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-04 == Outdated reference: A later version (-08) exists of draft-shirasaki-isp-shared-addr-04 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-03 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force I. Yamagata 3 Internet-Draft Y. Shirasaki 4 Intended status: Informational NTT Communications 5 Expires: January 13, 2011 A. Nakagawa 6 Japan Internet Exchange (JPIX) 7 J. Yamaguchi 8 IIJ 9 H. Ashida 10 iTSCOM 11 July 12, 2010 13 NAT444 14 draft-shirasaki-nat444-02 16 Abstract 18 This document describes one of the network models that are designed 19 for smooth transition to IPv6. It is called NAT444 model. NAT444 20 model is composed of IPv6, and IPv4 with Large Scale NAT (LSN). 22 NAT444 is the only scheme not to require replacing Customer Premises 23 Equipment (CPE) even if IPv4 address exhausted. But it must be noted 24 that NAT444 has serious restrictions i.e. it limits the number of 25 sessions per CPE so that rich applications such as AJAX and RSS feed 26 cannot work well. 28 Therefore, IPv6 which is free from such a difficulty has to be 29 introduced into the network at the same time. In other words, NAT444 30 is just a tool to make IPv6 transition easy to be swallowed. It is 31 designed for the days IPv4 and IPv6 co-existence. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 13, 2011. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definition of NAT444 Model . . . . . . . . . . . . . . . . . . 3 69 3. Behavior of NAT444 Model . . . . . . . . . . . . . . . . . . . 4 70 4. Pros and Cons of NAT444 Model . . . . . . . . . . . . . . . . . 5 71 4.1. Pros of NAT444 Model . . . . . . . . . . . . . . . . . . . 5 72 4.2. Cons of NAT444 Model . . . . . . . . . . . . . . . . . . . 5 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 79 Appendix A. Example IPv6 Transition Scenario . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The only permanent solution of the IPv4 address exhaustion is to 85 deploy IPv6. Now, just before the exhaustion, it's time to make a 86 transition to IPv6. 88 After the exhaustion, unless ISP takes any action, end users will not 89 be able to get IPv4 address. 91 The servers that have only IPv4 address will continue to exist on the 92 Internet after the IPv4 address exhaustion. In this situation, IPv6 93 only hosts cannot reach IPv4 only hosts. 95 This document explains NAT444 model that bridges the gap between the 96 coming IPv6 Internet and the present IPv4 Internet. 98 2. Definition of NAT444 Model 100 NAT444 Model is a network model that uses two Network Address and 101 Port Translators (NAPTs) with three types of IPv4 address blocks. 103 The first NAPT is in CPE, and the second NAPT is in Large Scale NAT 104 (LSN) [I-D.nishitani-cgn]. LSN is supposed to be installed in the 105 ISP's network. 107 The first IPv4 address block is Private Address [RFC1918] inside CPE. 108 The second one is an IPv4 Address block between CPEs and LSN. The 109 third one is IPv4 Global Addresses that is outside LSN. The ISPs 110 using NAT444 provide IPv6 connectivity by dual stack model. 112 (The IPv4 Internet) (The IPv6 Internet) 113 | | 114 +---------+ | 115 IPv4 Global Address | | 116 +--------+--------+ | 117 | LSN | | 118 +--------+--------+ | 119 IPv4 | | IPv6 120 +-------------+ 121 Dual Stack | 122 +---------------+----------------+ 123 | IPv4 NAT/IPv6 Dual Stack CPE | 124 +---------------+----------------+ 125 IPv4 Private Address / | 126 IPv6 Dual Stack | 127 +-----------+-------------+ 128 |IPv4/IPv6 Dual Stack host| 129 +-------------------------+ 131 3. Behavior of NAT444 Model 133 The IPv6 packets from the host reach the IPv6 Internet without using 134 NAT functionality. 136 The following figure shows the behavior of the IPv4 packet from the 137 host to the IPv4 server via two NATs. The first NAT in CPE 138 overwrites the Source IP Address and Source Port from 10.0.0.2:tt to 139 w.w.w.w:uu. Then the second NAT in LSN overwrites them from 140 w.w.w.w:uu to y.y.y.y:vv. Destination IP Address and Port are not 141 overwritten. 143 +-------------+ 144 (Port=80) | IPv4 Server | ^ 145 x.x.x.x-> +------+------+ : 146 | : 147 IPv4 Global Address | : 148 | : 149 (The IPv4 Internet):(Dst=x.x.x.x:80/Src=y.y.y.y:vv) 150 | : 151 IPv4 Global Address | : 152 | : 153 y.y.y.y-> +----+----+ : 154 (Port=vv) | LSN | ^ 155 z.z.z.z-> +----+----+ : 156 | : 157 IPv4 Address | :(Dst=x.x.x.x:80/Src=w.w.w.w:uu) 158 | : 159 w.w.w.w-> +-------+-------+ : 160 (Port=uu) | IPv4 NAT CPE | ^ 161 10.0.0.1-> +-------+-------+ : 162 | : 163 IPv4 Private Address| : 164 | : 165 10.0.0.2-> +----+----+ :(Dst=x.x.x.x:80/Src=10.0.0.2:tt) 166 (Port=tt) |IPv4 Host| 167 +---------+ 169 The following figure explains the behavior of returning IPv4 packet 170 via two NATs. The first NAT in LSN overwrites the Destination IP 171 Address and Port Number from y.y.y.y:vv to w.w.w.w:uu. Then the 172 second NAT in CPE overwrites them from w.w.w.w:u to 10.0.0.2:tt. 174 +-------------+ 175 (Port=80) | IPv4 Server | : 176 x.x.x.x-> +------+------+ : 177 | : 178 IPv4 Global Address | : 179 | : 180 (The IPv4 Internet):(Dst=y.y.y.y:vv/Src=x.x.x.x:80) 181 | : 182 IPv4 Global Address | : 183 | : 184 y.y.y.y-> +----+----+ : 185 (Port=vv) | LSN | v 186 z.z.z.z-> +----+----+ : 187 | : 188 IPv4 Address | :(Dst=w.w.w.w:uu/Src=x.x.x.x:80) 189 | : 190 w.w.w.w-> +-------+-------+ : 191 (Port=uu) | IPv4 NAT CPE | v 192 10.0.0.1-> +-------+-------+ : 193 | : 194 IPv4 Private Address | :(Dst=10.0.0.2:tt/Src=x.x.x.x:80) 195 | : 196 10.0.0.2-> +----+----+ : 197 (Port=tt) |IPv4 Host| v 198 +---------+ 200 4. Pros and Cons of NAT444 Model 202 4.1. Pros of NAT444 Model 204 This network model has following advantages. 206 - This is the only network model that doesn't require replacing CPEs 207 those are owned by customers. 208 - This network model is composed of the present technology. 209 - This network model doesn't require address family translation. 210 - This network model doesn't require DNS rewriting. 211 - This network model doesn't require additional fragment for the 212 packets because it doesn't use tunneling technology. 214 4.2. Cons of NAT444 Model 216 This network model has some technical restrictions. 218 - Some application such as SIP requires special treatment, because IP 219 address is written in the payload of the packet. Special treatment 220 means application itself aware double NAPT or both of two NAPTs 221 support inspecting and rewriting the packets. 222 - Because both IPv4 route and IPv6 route exist, it doubles the number 223 of IGP route inside the LSN. 224 - UPnP doesn't work with double NAPTs. 226 5. Acknowledgements 228 Thanks for the input and review by Shin Miyakawa, Shirou Niinobe, 229 Takeshi Tomochika, Tomohiro Fujisaki, Dai Nishino, JP address 230 community members, AP address community members and JPNIC members. 232 6. IANA Considerations 234 There are no IANA considerations. 236 7. Security Considerations 238 Each customer inside a LSN looks using the same Global Address from 239 outside an ISP. In case of incidents, the ISP must have the function 240 to trace back the record of each customer's access without using only 241 IP address. 243 If a Global Address of the LSN is listed on the blacklist, other 244 customers who share the same address could be affected. 246 8. References 248 8.1. Normative References 250 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 251 E. Lear, "Address Allocation for Private Internets", 252 BCP 5, RFC 1918, February 1996. 254 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 255 Problem Statement", RFC 4925, July 2007. 257 [I-D.nishitani-cgn] 258 Yamagata, I., Nishitani, T., Miyakawa, S., Nakagawa, A., 259 and H. Ashida, "Common requirements for IP address sharing 260 schemes", draft-nishitani-cgn-04 (work in progress), 261 March 2010. 263 8.2. Informative References 265 [I-D.shirasaki-isp-shared-addr] 266 Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 267 and H. Ashida, "ISP Shared Address", 268 draft-shirasaki-isp-shared-addr-04 (work in progress), 269 March 2010. 271 [I-D.shirasaki-nat444-isp-shared-addr] 272 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 273 and H. Ashida, "NAT444 addressing models", 274 draft-shirasaki-nat444-isp-shared-addr-03 (work in 275 progress), March 2010. 277 Appendix A. Example IPv6 Transition Scenario 279 The steps of IPv6 transition are as follows. 281 Step 1: Enabling softwire client in host 283 ISP provides IPv6 connectivity to customers with softwire [RFC4925]. 284 ISP installs LSN and softwire concentrator in its network. A 285 softwire client in host connects to the IPv6 internet via ISP's 286 concentrator. ISP can use existing IPv4 equipments. Customers can 287 just use existing CPE. 289 (The IPv4 Internet) (The IPv6 Internet) 290 | | IPv6 291 | +-----------+-----------+ 292 | | Softwire Concentrator | 293 | +-----------+-----------+ 294 +---------+----------+ ^ 295 IPv4 Global Address | : 296 +----------+----------+ : 297 | LSN | : 298 +----------+----------+ : 299 Any IPv4 Address | : IPv6 over IPv4 Softwire 300 (ISP Network) | : (e.g. IPv6 over IPv4 L2TP) 301 +----------+----------+ : 302 | IPv4 NAT only CPE | : 303 +----------+----------+ : 304 IPv4 Private Address | v 305 +---------------+-----------------+ 306 |IPv4/IPv6 Softwire Client in host| 307 +---------------------------------+ 309 Step 2: Enabling softwire client in CPE 310 A customer enables softwire client in CPE. A softwire client in CPE 311 connects to the IPv6 internet via ISP's concentrator. A Customer's 312 network is now dual stack. 314 (The IPv4 Internet) (The IPv6 Internet) 315 | | IPv6 316 | +----------+------------+ 317 | | Softwire Concentrator | 318 | +----------+------------+ 319 +---------+------------+ ^ 320 IPv4 Global Address | : 321 +----------+------------+ : 322 | LSN | : IPv6 over IPv4 Softwire 323 +----------+------------+ : (e.g. IPv6 over IPv4 L2TP) 324 Any IPv4 Address | : 325 (ISP Network) | v 326 +---------------+--------------------+ 327 |IPv4 NAT/IPv6 Softwire client in CPE| 328 +---------------+--------------------+ 329 IPv4 Private Address / | 330 IPv6 Dual Stack | 331 +-----------+-------------+ 332 |IPv4/IPv6 Dual Stack host| 333 +-------------------------+ 335 Step 3: Moving on to dual stack 337 ISP provides dual stack access to CPE. A CPE uplink is now dual 338 stack. 340 (The IPv4 Internet) (The IPv6 Internet) 341 | | 342 +---------+ | 343 IPv4 Global Address | | 344 +--------+--------+ | 345 | LSN | | IPv6 346 +--------+--------+ | 347 Any IPv4 Address / | | 348 IPv6 Dual Stack +-------------+ 349 (ISP Network) | 350 +---------------+----------------+ 351 | IPv4 NAT/IPv6 Dual Stack CPE | 352 +---------------+----------------+ 353 IPv4 Private Address / | 354 IPv6 Dual Stack | 355 +-----------+-------------+ 356 |IPv4/IPv6 Dual Stack host| 357 +-------------------------+ 359 Step 4: Moving on to pure IPv6 361 IPv6 transition completes. 363 (The IPv6 Internet) 364 | 365 IPv6 | 366 +--------+----------+ 367 | IPv6 CPE | 368 +--------+----------+ 369 IPv6 | 370 +--------+----------+ 371 | IPv6 host | 372 +-------------------+ 374 Authors' Addresses 376 Ikuhei Yamagata 377 NTT Communications Corporation 378 Granpark Tower 17F, 3-4-1 Shibaura, Minato-ku 379 Tokyo 108-8118 380 Japan 382 Phone: +81 3 6733 8671 383 Email: ikuhei@nttv6.jp 385 Yasuhiro Shirasaki 386 NTT Communications Corporation 387 NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku 388 Tokyo 100-8019 389 Japan 391 Phone: +81 3 6700 8530 392 Email: yasuhiro@nttv6.jp 394 Akira Nakagawa 395 Japan Internet Exchange Co., Ltd. (JPIX) 396 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 397 Tokyo 100-0004 398 Japan 400 Phone: +81 90 9242 2717 401 Email: a-nakagawa@jpix.ad.jp 402 Jiro Yamaguchi 403 Internet Initiative Japan Inc. 404 Kakyoin Square Bldg., 15F, 1-1-20 Kakyoin, Aoba-ku 405 Sendai 980-0013 406 Japan 408 Phone: +81 22 216 5650 409 Email: jiro-y@iij.ad.jp 411 Hiroyuki Ashida 412 its communications Inc. 413 3-5-7 Hisamoto Takatsu-ku Kawasaki-shi 414 Kanagawa 213-0011 415 Japan 417 Email: ashida@itscom.ad.jp