idnits 2.17.1 draft-shirasaki-nat444-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 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 (October 19, 2009) is 5274 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 259, but no explicit reference was found in the text == Unused Reference: 'PROP58' is defined on line 272, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-shirasaki-isp-shared-addr-03 == Outdated reference: A later version (-05) exists of draft-nishitani-cgn-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Shirasaki, Ed. 3 Internet-Draft I. Yamagata 4 Intended status: Informational NTT Communications 5 Expires: April 22, 2010 A. Nakagawa 6 KDDI CORPORATION 7 J. Yamaguchi 8 IIJ 9 H. Ashida 10 iTSCOM 11 October 19, 2009 13 NAT444 14 draft-shirasaki-nat444-00 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 22, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document describes one of the network models that are designed 53 for smooth transition to IPv6. It is called NAT444 model. NAT444 54 model is composed of IPv6, and IPv4 with Large Scale NAT (LSN). 56 NAT444 is the only scheme not to require replacing Customer Premises 57 Equipment (CPE) even if IPv4 address exhausted. But it must be noted 58 that NAT444 has serious restrictions i.e. it limits the number of 59 sessions per CPE so that rich applications such as AJAX and RSS feed 60 cannot work well. 62 Therefore, IPv6 which is free from such a difficulty has to be 63 introduced into the network at the same time. In other words, NAT444 64 is just a tool to make IPv6 transition easy to be swallowed. It is 65 designed for the days IPv4 and IPv6 co-existence. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Definition of NAT444 Model . . . . . . . . . . . . . . . . . . 4 71 3. Behavior of NAT444 Model . . . . . . . . . . . . . . . . . . . 5 72 4. Pros and Cons of NAT444 Model . . . . . . . . . . . . . . . . 6 73 4.1. Pros of NAT444 Model . . . . . . . . . . . . . . . . . . . 6 74 4.2. Cons of NAT444 Model . . . . . . . . . . . . . . . . . . . 6 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 81 Appendix A. Example IPv6 Transition Scenario . . . . . . . . . . 8 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 The only permanent solution of the IPv4 address exhaustion is to 87 deploy IPv6. Now, just before the exhaustion, it's time to make a 88 transition to IPv6. 90 After the exhaustion, unless ISP takes any action, end users will not 91 be able to get IPv4 address. 93 The servers that have only IPv4 address will continue to exist on the 94 Internet after the IPv4 address exhaustion. In this situation, IPv6 95 only hosts cannot reach IPv4 only hosts. 97 This document explains NAT444 model that bridges the gap between the 98 coming IPv6 Internet and the present IPv4 Internet. 100 2. Definition of NAT444 Model 102 NAT444 Model is a network model that uses two Network Address and 103 Port Translators (NAPTs) with three types of IPv4 address blocks. 105 The first NAPT is in CPE, and the second NAPT is in Large Scale NAT 106 (LSN) [I-D.nishitani-cgn]. LSN is supposed to be installed in the 107 ISP's network. 109 The first IPv4 address block is Private Address [RFC1918] inside CPE. 110 The second one is an IPv4 Address block between CPEs and LSN. The 111 third one is IPv4 Global Addresses that is outside LSN. The ISPs 112 using NAT444 provide IPv6 connectivity by dual stack model. 114 (The IPv4 Internet) (The IPv6 Internet) 115 | | 116 +---------+ | 117 IPv4 Global Address | | 118 +--------+--------+ | 119 | LSN | | 120 +--------+--------+ | 121 IPv4 | | IPv6 122 +-------------+ 123 Dual Stack | 124 +---------------+----------------+ 125 | IPv4 NAT/IPv6 Dual Stack CPE | 126 +---------------+----------------+ 127 IPv4 Private Address / | 128 IPv6 Dual Stack | 129 +-----------+-------------+ 130 |IPv4/IPv6 Dual Stack host| 131 +-------------------------+ 133 3. Behavior of NAT444 Model 135 The IPv6 packets from the host reach the IPv6 Internet without using 136 NAT functionality. 138 The following figure shows the behavior of the IPv4 packet from the 139 host to the IPv4 server via two NATs. The first NAT in CPE 140 overwrites the Source IP Address and Source Port from 10.0.0.2:tt to 141 w.w.w.w:uu. Then the second NAT in LSN overwrites them from 142 w.w.w.w:uu to y.y.y.y:vv. Destination IP Address and Port are not 143 overwritten. 145 +-------------+ 146 (Port=80) | IPv4 Server | ^ 147 x.x.x.x-> +------+------+ : 148 | : 149 IPv4 Global Address | : 150 | : 151 (The IPv4 Internet):(Dst=x.x.x.x:80/Src=y.y.y.y:vv) 152 | : 153 IPv4 Global Address | : 154 | : 155 y.y.y.y-> +----+----+ : 156 (Port=vv) | LSN | ^ 157 z.z.z.z-> +----+----+ : 158 | : 159 IPv4 Address | :(Dst=x.x.x.x:80/Src=w.w.w.w:uu) 160 | : 161 w.w.w.w-> +-------+-------+ : 162 (Port=uu) | IPv4 NAT CPE | ^ 163 10.0.0.1-> +-------+-------+ : 164 | : 165 IPv4 Private Address| : 166 | : 167 10.0.0.2-> +----+----+ :(Dst=x.x.x.x:80/Src=10.0.0.2:tt) 168 (Port=tt) |IPv4 Host| 169 +---------+ 171 The following figure explains the behavior of returning IPv4 packet 172 via two NATs. The first NAT in LSN overwrites the Destination IP 173 Address and Port Number from y.y.y.y:vv to w.w.w.w:uu. Then the 174 second NAT in CPE overwrites them from w.w.w.w:u to 10.0.0.2:tt. 176 +-------------+ 177 (Port=80) | IPv4 Server | : 178 x.x.x.x-> +------+------+ : 179 | : 180 IPv4 Global Address | : 181 | : 182 (The IPv4 Internet):(Dst=y.y.y.y:vv/Src=x.x.x.x:80) 183 | : 184 IPv4 Global Address | : 185 | : 186 y.y.y.y-> +----+----+ : 187 (Port=vv) | LSN | v 188 z.z.z.z-> +----+----+ : 189 | : 190 IPv4 Address | :(Dst=w.w.w.w:uu/Src=x.x.x.x:80) 191 | : 192 w.w.w.w-> +-------+-------+ : 193 (Port=uu) | IPv4 NAT CPE | v 194 10.0.0.1-> +-------+-------+ : 195 | : 196 IPv4 Private Address | :(Dst=10.0.0.2:tt/Src=x.x.x.x:80) 197 | : 198 10.0.0.2-> +----+----+ : 199 (Port=tt) |IPv4 Host| v 200 +---------+ 202 4. Pros and Cons of NAT444 Model 204 4.1. Pros of NAT444 Model 206 This network model has following advantages. 208 - This is the only network model that doesn't require replacing CPEs 209 those are owned by customers. 210 - This network model is composed of the present technology. 211 - This network model doesn't require address family translation. 212 - This network model doesn't require DNS rewriting. 213 - This network model doesn't require additional fragment for the 214 packets because it doesn't use tunneling technology. 216 4.2. Cons of NAT444 Model 218 This network model has some technical restrictions. 220 - Some application such as SIP requires special treatment, because IP 221 address is written in the payload of the packet. Special treatment 222 means application itself aware double NAPT or both of two NAPTs 223 support inspecting and rewriting the packets. 224 - Because both IPv4 route and IPv6 route exist, it doubles the number 225 of IGP route inside the LSN. 226 - UPnP doesn't work with double NAPTs. 228 5. Acknowledgements 230 Thanks for the input and review by Shin Miyakawa, Shirou Niinobe, 231 Takeshi Tomochika, Tomohiro Fujisaki, Dai Nishino, JP address 232 community members, AP address community members and JPNIC members. 234 6. IANA Considerations 236 There are no IANA considerations. 238 7. Security Considerations 240 Each customer inside a LSN looks using the same Global Address from 241 outside an ISP. In case of incidents, the ISP must have the function 242 to trace back the record of each customer's access without using only 243 IP address. 245 If a Global Address of the LSN is listed on the blacklist, other 246 customers who share the same address could be affected. 248 8. References 250 8.1. Normative References 252 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 253 E. Lear, "Address Allocation for Private Internets", 254 BCP 5, RFC 1918, February 1996. 256 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 257 Problem Statement", RFC 4925, July 2007. 259 [I-D.shirasaki-isp-shared-addr] 260 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 261 and H. Ashida, "ISP Shared Address", 262 draft-shirasaki-isp-shared-addr-03 (work in progress), 263 September 2009. 265 [I-D.nishitani-cgn] 266 Nishitani, T., Miyakawa, S., Nakagawa, A., and H. Ashida, 267 "Common Functions of Large Scale NAT (LSN)", 268 draft-nishitani-cgn-02 (work in progress), June 2009. 270 8.2. Informative References 272 [PROP58] Niinobe, S., Tomochika, T., Yamaguchi, J., Nishino, D., 273 Ashida, H., Nakagawa, A., and T. Hosaka, "Proposal to 274 create IPv4 shared use address space among LIRs", 2008, 275 . 278 Appendix A. Example IPv6 Transition Scenario 280 The steps of IPv6 transition are as follows. 282 Step 1: Enabling softwire client in host 284 ISP provides IPv6 connectivity to customers with softwire [RFC4925]. 285 ISP installs LSN and softwire concentrator in its network. A 286 softwire client in host connects to the IPv6 internet via ISP's 287 concentrator. ISP can use existing IPv4 equipments. Customers can 288 just use existing CPE. 290 (The IPv4 Internet) (The IPv6 Internet) 291 | | IPv6 292 | +-----------+-----------+ 293 | | Softwire Concentrator | 294 | +-----------+-----------+ 295 +---------+----------+ ^ 296 IPv4 Global Address | : 297 +----------+----------+ : 298 | LSN | : 299 +----------+----------+ : 300 Any IPv4 Address | : IPv6 over IPv4 Softwire 301 (ISP Network) | : (e.g. IPv6 over IPv4 L2TP) 302 +----------+----------+ : 303 | IPv4 NAT only CPE | : 304 +----------+----------+ : 305 IPv4 Private Address | v 306 +---------------+-----------------+ 307 |IPv4/IPv6 Softwire Client in host| 308 +---------------------------------+ 310 Step 2: Enabling softwire client in CPE 312 A customer enables softwire client in CPE. A softwire client in CPE 313 connects to the IPv6 internet via ISP's concentrator. A Customer's 314 network is now dual stack. 316 (The IPv4 Internet) (The IPv6 Internet) 317 | | IPv6 318 | +----------+------------+ 319 | | Softwire Concentrator | 320 | +----------+------------+ 321 +---------+------------+ ^ 322 IPv4 Global Address | : 323 +----------+------------+ : 324 | LSN | : IPv6 over IPv4 Softwire 325 +----------+------------+ : (e.g. IPv6 over IPv4 L2TP) 326 Any IPv4 Address | : 327 (ISP Network) | v 328 +---------------+--------------------+ 329 |IPv4 NAT/IPv6 Softwire client in CPE| 330 +---------------+--------------------+ 331 IPv4 Private Address / | 332 IPv6 Dual Stack | 333 +-----------+-------------+ 334 |IPv4/IPv6 Dual Stack host| 335 +-------------------------+ 337 Step 3: Moving on to dual stack 339 ISP provides dual stack access to CPE. A CPE uplink is now dual 340 stack. 342 (The IPv4 Internet) (The IPv6 Internet) 343 | | 344 +---------+ | 345 IPv4 Global Address | | 346 +--------+--------+ | 347 | LSN | | IPv6 348 +--------+--------+ | 349 Any IPv4 Address / | | 350 IPv6 Dual Stack +-------------+ 351 (ISP Network) | 352 +---------------+----------------+ 353 | IPv4 NAT/IPv6 Dual Stack CPE | 354 +---------------+----------------+ 355 IPv4 Private Address / | 356 IPv6 Dual Stack | 357 +-----------+-------------+ 358 |IPv4/IPv6 Dual Stack host| 359 +-------------------------+ 361 Step 4: Moving on to pure IPv6 362 IPv6 transition completes. 364 (The IPv6 Internet) 365 | 366 IPv6 | 367 +--------+----------+ 368 | IPv6 CPE | 369 +--------+----------+ 370 IPv6 | 371 +--------+----------+ 372 | IPv6 host | 373 +-------------------+ 375 Authors' Addresses 377 Yasuhiro Shirasaki (editor) 378 NTT Communications Corporation 379 NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku 380 Tokyo 100-8019 381 Japan 383 Phone: +81 3 6700 8530 384 Email: yasuhiro@nttv6.jp 386 Ikuhei Yamagata 387 NTT Communications Corporation 388 Granpark Tower 17F, 3-4-1 Shibaura, Minato-ku 389 Tokyo 108-8118 390 Japan 392 Phone: +81 3 6733 8671 393 Email: ikuhei@nttv6.jp 395 Akira Nakagawa 396 KDDI CORPORATION 397 GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku 398 Tokyo 102-8460 399 Japan 401 Email: ai-nakagawa@kddi.com 402 Jiro Yamaguchi 403 Internet Initiative Japan Inc. 404 Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho, Chiyoda-ku 405 Tokyo 101-0051 406 Japan 408 Phone: +81 3 5205 6500 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