idnits 2.17.1 draft-shirasaki-nat444-isp-shared-addr-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'PROP58' is defined on line 293, 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-03 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Yamaguchi, Ed. 3 Internet-Draft IIJ 4 Intended status: Informational Y. Shirasaki 5 Expires: September 9, 2010 S. Miyakawa 6 NTT Communications 7 A. Nakagawa 8 KDDI CORPORATION 9 H. Ashida 10 iTSCOM 11 March 8, 2010 13 NAT444 addressing models 14 draft-shirasaki-nat444-isp-shared-addr-03 16 Abstract 18 This document describes addressing models of NAT444. There are some 19 addressing models of NAT444. The addressing models have some issues 20 of network behaviors, operations, and addressing. This document 21 helps network architects to use NAT444 after IPv4 address exhaustion. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 9, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Addressing Models . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Global Address . . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Private Address . . . . . . . . . . . . . . . . . . . . . . 3 67 2.2.1. Policy Based Routing Issue . . . . . . . . . . . . . . 3 68 2.2.2. Address Block Duplication Issue . . . . . . . . . . . . 3 69 2.2.3. Class-E Address (240/4) . . . . . . . . . . . . . . . . 3 70 2.2.4. ISP Shared Address . . . . . . . . . . . . . . . . . . 4 71 3. Example Architectures . . . . . . . . . . . . . . . . . . . . . 4 72 3.1. Direct Routing inside LSN . . . . . . . . . . . . . . . . . 4 73 3.2. LSN Bypassing . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.3. Global Address Customers inside LSN . . . . . . . . . . . . 6 75 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 80 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 NAT444 [I-D.shirasaki-nat444] is one of solutions after IPv4 address 86 exhaustion. ISP can select some addressing models of NAT444. The 87 addressing models have some issues of network behaviors, operations, 88 and addressing. This document describes these issues and solutions. 89 It boosts up to deploy the IPv6 Internet. 91 2. Addressing Models 93 The key of addressing model is the address block between Customer 94 Premises Equipment (CPE) and Large Scale NAT (LSN) 95 [I-D.nishitani-cgn]. It's mentioned in this section. The best 96 addressing model is "ISP Shared Address" which is defined in 97 [I-D.shirasaki-isp-shared-addr] and briefly described in this 98 section. 100 2.1. Global Address 102 ISP cannot assign IPv4 Global Address any more after the exhaustion. 104 2.2. Private Address 106 It has two major problems. 108 2.2.1. Policy Based Routing Issue 110 If both source and destination address of the packet are inside LSN, 111 it has to go through LSN. The reason is that some servers reject 112 receiving packets when the source address of receiving packet is 113 Private Address. Therefore packets have to go through the LSN for 114 rewriting the source address from Private Address to Global Address. 115 Additionally, if Private Address and Global Address co-exist inside 116 LSN, the ISP has to use Policy Based Routing (PBR). 118 2.2.2. Address Block Duplication Issue 120 The Private Address in ISP's network could conflict with its 121 customer's network address. Many CPEs between customer's network and 122 ISP's network cannot route the packet under this situation. To avoid 123 this, ISP has to negotiate with its all customers not to use the 124 reserved Private Address block. 126 2.2.3. Class-E Address (240/4) 128 It is known that some equipment such as routers and servers reject 129 packets from or to this address block. So, to use this address block 130 in ISP's network, ISP has to request its customers to replace their 131 equipment. In addition to that, ISP might have to replace their 132 equipment when it doesn't handle Class-E address packets properly. 134 2.2.4. ISP Shared Address 136 ISP Shared Address is the newly defined IPv4 address block that is to 137 be allocated from IANA free pool. It doesn't have any problem. 138 Spending some blocks from the exhausting IANA free pool could be 139 regarded as a problem, but from long view, this problem is much 140 smaller than its great merit. ISP Shared Address is defined in 141 [I-D.shirasaki-isp-shared-addr]. 143 3. Example Architectures 145 This section explains example architectures how to design NAT444 with 146 ISP Shared Address. 148 3.1. Direct Routing inside LSN 150 This architecture enables direct communication between customers 151 inside same LSN. It has the following advantages. 153 o The packets don't go through LSN. (No hairpining) 155 o The customers inside LSN can use bidirectional applications (e.g. 156 TV Conference, VPN). 158 o No need to use Policy Based Routing. 160 (The IPv4 Internet) 161 | Global Address 162 +----+----+ 163 | LSN | 164 +----+----+ 165 | 166 ISP Shared +-----------+----------+ ISP Shared 167 Address | .......... | Address 168 +----+----+ : : +----+----+ 169 | CPE NAT | : : | CPE NAT | 170 +----+----+ : : +----+----+ 171 Private | : : | Private 172 Address | v v | Address 173 +----+----+ +----+----+ 174 |IPv4 Host| |IPv4 Host| 175 +---------+ +---------+ 177 3.2. LSN Bypassing 179 This architecture is bypassing the NAT function of LSN. It has the 180 following advantage. 182 o The customers inside an ISP can use bidirectional applications 183 (e.g. TV Conference, VPN). 185 o Any communication in single ISP doesn't consume LSN external port. 187 o ISP's servers outside LSN can access CPE. (e.g. ICMP echo, SNMP, 188 remote access) 190 o ISP's servers outside LSN can distinguish which customer's 191 connection it receives. (e.g. DNS, Mail) 193 (The IPv4 Internet) 194 | 195 | +--------+ Network Monitor 196 | | Server | (ICMP echo, SNMP) 197 | +----+---+ DNS, Mail, Web, etc 198 Global | | ^ 199 Address +----------------------+ : 200 | .................... 201 | . : | 202 +----+----+ : : +----+----+ bypass NAT: 203 | LSN | : bypass : | LSN | Dst=ISP's Global Address 204 +----+----+ : NAT : +----+----+ or ISP Shared Address 205 ISP Shared | : : | 206 Address | : : | ISP Shared Address 207 +----+----+ : : +----+----+ 208 | CPE NAT | : : | CPE NAT | 209 +----+----+ : : +----+----+ 210 Private | : : | Private 211 Address | v v | Address 212 +----+----+ +----+----+ 213 |IPv4 Host| |IPv4 Host| 214 +---------+ +---------+ 216 3.3. Global Address Customers inside LSN 218 This architecture enables co-existing Global Address and ISP Shared 219 Address inside LSN. 221 It enables direct communications from ISP Shared Address customer to 222 Global Address customer inside same LSN. It has the following 223 advantage. 225 o The ISP can put ISP Shared Address customer and Global Address 226 customer in the same concentrator. 228 o The customers inside LSN can use bidirectional applications (e.g. 229 TV Conference, VPN). 231 o No need to use Policy Based Routing. 233 (The IPv4 Internet) 234 | 235 | Global Address 236 +----+----+ 237 | LSN | bypass NAT: Src/Dst=Global Address 238 +----+----+ 239 | Global Address and ISP Shared Address co-existing 240 +----------------------+ 241 | ......... | 242 +----+----+ : : +----+----+ 243 | Firewall| : : | CPE NAT | 244 +----+----+ : : +----+----+ 245 Global | : : | Private 246 Address | v : | Address 247 +-----+-----+ +----+----+ 248 |IPv4 Server| |IPv4 Host| 249 +-----------+ +---------+ 251 4. Acknowledgements 253 Thanks for the input and review by Shirou Niinobe, Takeshi Tomochika, 254 Tomohiro Fujisaki, Dai Nishino, JP address community members, AP 255 address community members and JPNIC members. 257 5. IANA Considerations 259 IANA is to allocate a certain size of address block from IANA free 260 pool. The size of it is described in [I-D.shirasaki-isp-shared-addr] 262 6. Security Considerations 264 There are no security considerations. 266 7. References 268 7.1. Normative References 270 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 271 E. Lear, "Address Allocation for Private Internets", 272 BCP 5, RFC 1918, February 1996. 274 [I-D.shirasaki-isp-shared-addr] 275 Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 276 and H. Ashida, "ISP Shared Address", 277 draft-shirasaki-isp-shared-addr-03 (work in progress), 278 September 2009. 280 [I-D.nishitani-cgn] 281 Nishitani, T., Yamagata, I., Miyakawa, S., Nakagawa, A., 282 and H. Ashida, "Common Functions of Large Scale NAT 283 (LSN)", draft-nishitani-cgn-03 (work in progress), 284 November 2009. 286 [I-D.shirasaki-nat444] 287 Shirasaki, Y., Yamagata, I., Nakagawa, A., Yamaguchi, J., 288 and H. Ashida, "NAT444", draft-shirasaki-nat444-00 (work 289 in progress), October 2009. 291 7.2. Informative References 293 [PROP58] Niinobe, S., Tomochika, T., Yamaguchi, J., Nishino, D., 294 Ashida, H., Nakagawa, A., and T. Hosaka, "Proposal to 295 create IPv4 shared use address space among LIRs", 2008, 296 . 299 Authors' Addresses 301 Jiro Yamaguchi (editor) 302 Internet Initiative Japan Inc. 303 Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho, Chiyoda-ku 304 Tokyo 101-0051 305 Japan 307 Phone: +81 3 5205 6500 308 Email: jiro-y@iij.ad.jp 310 Yasuhiro Shirasaki 311 NTT Communications Corporation 312 NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku 313 Tokyo 100-8019 314 Japan 316 Phone: +81 3 6700 8530 317 Email: yasuhiro@nttv6.jp 319 Shin Miyakawa 320 NTT Communications Corporation 321 Granpark Tower 17F, 3-4-1 Shibaura, Minato-ku 322 Tokyo 108-8118 323 Japan 325 Phone: +81 3 6733 8671 326 Email: miyakawa@nttv6.jp 328 Akira Nakagawa 329 KDDI CORPORATION 330 GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku 331 Tokyo 102-8460 332 Japan 334 Email: ai-nakagawa@kddi.com 335 Hiroyuki Ashida 336 its communications Inc. 337 3-5-7 Hisamoto Takatsu-ku Kawasaki-shi 338 Kanagawa 213-0011 339 Japan 341 Email: ashida@itscom.ad.jp