idnits 2.17.1 draft-shirasaki-nat444-isp-shared-addr-06.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 : ---------------------------------------------------------------------------- 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 (July 11, 2011) is 4673 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1918' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'PROP58' is defined on line 287, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-shirasaki-isp-shared-addr-05 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-01 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-03 Summary: 0 errors (**), 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 3 Internet-Draft IIJ 4 Intended status: Informational Y. Shirasaki 5 Expires: January 12, 2012 S. Miyakawa 6 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 iTSCOM 11 July 11, 2011 13 NAT444 addressing models 14 draft-shirasaki-nat444-isp-shared-addr-06 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 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 12, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Addressing Models . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Global Address . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Private Address . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2.1. Policy Based Routing Issue . . . . . . . . . . . . . . 3 62 2.2.2. Address Block Duplication Issue . . . . . . . . . . . . 3 63 2.2.3. Class-E Address (240/4) . . . . . . . . . . . . . . . . 3 64 2.2.4. ISP Shared Address . . . . . . . . . . . . . . . . . . 4 65 3. Example Architectures . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Direct Routing inside CGN . . . . . . . . . . . . . . . . . 4 67 3.2. CGN Bypassing . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.3. Global Address Customers inside CGN . . . . . . . . . . . . 6 69 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 NAT444 [I-D.shirasaki-nat444] is one of solutions after IPv4 address 80 exhaustion. ISP can select some addressing models of NAT444. The 81 addressing models have some issues of network behaviors, operations, 82 and addressing. This document describes these issues and solutions. 83 It boosts up to deploy the IPv6 Internet. 85 2. Addressing Models 87 The key of addressing model is the address block between Customer 88 Premises Equipment (CPE) and Carrier Grade NAT (CGN) 89 [I-D.ietf-behave-lsn-requirements]. It's mentioned in this section. 90 The best addressing model is "ISP Shared Address" which is defined in 91 [I-D.shirasaki-isp-shared-addr] and briefly described in this 92 section. 94 2.1. Global Address 96 ISP cannot assign IPv4 Global Address any more after the exhaustion. 98 2.2. Private Address 100 It has two major problems. 102 2.2.1. Policy Based Routing Issue 104 If both source and destination address of the packet are inside CGN, 105 it has to go through CGN. The reason is that some servers reject 106 receiving packets when the source address of receiving packet is 107 Private Address. Therefore packets have to go through the CGN for 108 rewriting the source address from Private Address to Global Address. 109 Additionally, if Private Address and Global Address co-exist inside 110 CGN, the ISP has to use Policy Based Routing (PBR). 112 2.2.2. Address Block Duplication Issue 114 The Private Address in ISP's network could conflict with its 115 customer's network address. Many CPEs between customer's network and 116 ISP's network cannot route the packet under this situation. To avoid 117 this, ISP has to negotiate with its all customers not to use the 118 reserved Private Address block. 120 2.2.3. Class-E Address (240/4) 122 It is known that some equipment such as routers and servers reject 123 packets from or to this address block. So, to use this address block 124 in ISP's network, ISP has to request its customers to replace their 125 equipment. In addition to that, ISP might have to replace their 126 equipment when it doesn't handle Class-E address packets properly. 128 2.2.4. ISP Shared Address 130 ISP Shared Address is the newly defined IPv4 address block that is to 131 be allocated from IANA free pool. It doesn't have any problem. 132 Spending some blocks from the exhausting IANA free pool could be 133 regarded as a problem, but from long view, this problem is much 134 smaller than its great merit. ISP Shared Address is defined in 135 [I-D.shirasaki-isp-shared-addr]. 137 3. Example Architectures 139 This section explains example architectures how to design NAT444 with 140 ISP Shared Address. 142 3.1. Direct Routing inside CGN 144 This architecture enables direct communication between customers 145 inside same CGN. It has the following advantages. 147 o The packets don't go through CGN. (No hairpining) 149 o The customers inside CGN can use bidirectional applications (e.g. 150 TV Conference, VPN). 152 o No need to use Policy Based Routing. 154 (The IPv4 Internet) 155 | Global Address 156 +----+----+ 157 | CGN | 158 +----+----+ 159 | 160 ISP Shared +-----------+----------+ ISP Shared 161 Address | .......... | Address 162 +----+----+ : : +----+----+ 163 | CPE NAT | : : | CPE NAT | 164 +----+----+ : : +----+----+ 165 Private | : : | Private 166 Address | v v | Address 167 +----+----+ +----+----+ 168 |IPv4 Host| |IPv4 Host| 169 +---------+ +---------+ 171 3.2. CGN Bypassing 173 This architecture is bypassing the NAT function of CGN. It has the 174 following advantage. 176 o The customers inside an ISP can use bidirectional applications 177 (e.g. TV Conference, VPN). 179 o Any communication in single ISP doesn't consume CGN external port. 181 o ISP's servers outside CGN can access CPE. (e.g. ICMP echo, SNMP, 182 remote access) 184 o ISP's servers outside CGN can distinguish which customer's 185 connection it receives. (e.g. DNS, Mail) 187 (The IPv4 Internet) 188 | 189 | +--------+ Network Monitor 190 | | Server | (ICMP echo, SNMP) 191 | +----+---+ DNS, Mail, Web, etc 192 Global | | ^ 193 Address +----------------------+ : 194 | .................... 195 | . : | 196 +----+----+ : : +----+----+ bypass NAT: 197 | CGN | : bypass : | CGN | Dst=ISP's Global Address 198 +----+----+ : NAT : +----+----+ or ISP Shared Address 199 ISP Shared | : : | 200 Address | : : | ISP Shared Address 201 +----+----+ : : +----+----+ 202 | CPE NAT | : : | CPE NAT | 203 +----+----+ : : +----+----+ 204 Private | : : | Private 205 Address | v v | Address 206 +----+----+ +----+----+ 207 |IPv4 Host| |IPv4 Host| 208 +---------+ +---------+ 210 3.3. Global Address Customers inside CGN 212 This architecture enables co-existing Global Address and ISP Shared 213 Address inside CGN. 215 It enables direct communications from ISP Shared Address customer to 216 Global Address customer inside same CGN. It has the following 217 advantage. 219 o The ISP can put ISP Shared Address customer and Global Address 220 customer in the same concentrator. 222 o The customers inside CGN can use bidirectional applications (e.g. 223 TV Conference, VPN). 225 o No need to use Policy Based Routing. 227 (The IPv4 Internet) 228 | 229 | Global Address 230 +----+----+ 231 | CGN | bypass NAT: Src/Dst=Global Address 232 +----+----+ 233 | Global Address and ISP Shared Address co-existing 234 +----------------------+ 235 | ......... | 236 +----+----+ : : +----+----+ 237 | Firewall| : : | CPE NAT | 238 +----+----+ : : +----+----+ 239 Global | : : | Private 240 Address | v : | Address 241 +-----+-----+ +----+----+ 242 |IPv4 Server| |IPv4 Host| 243 +-----------+ +---------+ 245 4. Acknowledgements 247 Thanks for the input and review by Shirou Niinobe, Takeshi Tomochika, 248 Tomohiro Fujisaki, Dai Nishino, JP address community members, AP 249 address community members and JPNIC members. 251 5. IANA Considerations 253 IANA is to allocate a certain size of address block from IANA free 254 pool. The size of it is described in [I-D.shirasaki-isp-shared-addr] 256 6. Security Considerations 258 There are no security considerations. 260 7. References 262 7.1. Normative References 264 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 265 E. Lear, "Address Allocation for Private Internets", 266 BCP 5, RFC 1918, February 1996. 268 [I-D.shirasaki-isp-shared-addr] 269 Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 270 and H. Ashida, "ISP Shared Address", 271 draft-shirasaki-isp-shared-addr-05 (work in progress), 272 September 2010. 274 [I-D.ietf-behave-lsn-requirements] 275 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 276 and H. Ashida, "Common requirements for IP address sharing 277 schemes", draft-ietf-behave-lsn-requirements-01 (work in 278 progress), March 2011. 280 [I-D.shirasaki-nat444] 281 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 282 and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work 283 in progress), January 2011. 285 7.2. Informative References 287 [PROP58] Niinobe, S., Tomochika, T., Yamaguchi, J., Nishino, D., 288 Ashida, H., Nakagawa, A., and T. Hosaka, "Proposal to 289 create IPv4 shared use address space among LIRs", 2008, 290 . 293 Authors' Addresses 295 Jiro Yamaguchi 296 Internet Initiative Japan Inc. 297 Kakyoin Square Bldg., 15F, 1-1-20 Kakyoin, Aoba-ku 298 Sendai 980-0013 299 Japan 301 Phone: +81 22 216 5650 302 Email: jiro-y@iij.ad.jp 304 Yasuhiro Shirasaki 305 NTT Communications Corporation 306 NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku 307 Tokyo 100-8019 308 Japan 310 Phone: +81 3 6700 8530 311 Email: yasuhiro@nttv6.jp 313 Shin Miyakawa 314 NTT Communications Corporation 315 Granpark Tower 17F, 3-4-1 Shibaura, Minato-ku 316 Tokyo 108-8118 317 Japan 319 Phone: +81 3 6733 8671 320 Email: miyakawa@nttv6.jp 322 Akira Nakagawa 323 Japan Internet Exchange Co., Ltd. (JPIX) 324 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 325 Tokyo 100-0004 326 Japan 328 Phone: +81 90 9242 2717 329 Email: a-nakagawa@jpix.ad.jp 330 Hiroyuki Ashida 331 its communications Inc. 332 3-5-7 Hisamoto Takatsu-ku Kawasaki-shi 333 Kanagawa 213-0011 334 Japan 336 Email: ashida@itscom.ad.jp