idnits 2.17.1 draft-shirasaki-nat444-isp-shared-addr-08.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2012) is 4313 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-shirasaki-isp-shared-addr-07 == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-07 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-05 Summary: 0 errors (**), 0 flaws (~~), 4 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 Fiber 26 Network 4 Intended status: Informational Y. Shirasaki 5 Expires: January 6, 2013 S. Miyakawa 6 NTT Communications 7 A. Nakagawa 8 Japan Internet Exchange (JPIX) 9 H. Ashida 10 IS Consulting G.K. 11 July 5, 2012 13 NAT444 addressing models 14 draft-shirasaki-nat444-isp-shared-addr-08 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 6, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Addressing Models . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Global Address . . . . . . . . . . . . . . . . . . . . . . 4 72 2.2. Private Address . . . . . . . . . . . . . . . . . . . . . . 4 73 2.2.1. Policy Based Routing Issue . . . . . . . . . . . . . . 4 74 2.2.2. Address Block Duplication Issue . . . . . . . . . . . . 4 75 2.2.3. Class-E Address (240/4) . . . . . . . . . . . . . . . . 4 76 2.2.4. ISP Shared Address . . . . . . . . . . . . . . . . . . 5 77 3. Example Architectures . . . . . . . . . . . . . . . . . . . . . 5 78 3.1. Direct Routing inside CGN . . . . . . . . . . . . . . . . . 5 79 3.2. CGN Bypassing . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.3. Global Address Customers inside CGN . . . . . . . . . . . . 7 81 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 84 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 NAT444 [I-D.shirasaki-nat444] is one of solutions after IPv4 address 90 exhaustion. ISP can select some addressing models of NAT444. The 91 addressing models have some issues of network behaviors, operations, 92 and addressing. This document describes these issues and solutions. 93 It boosts up to deploy the IPv6 Internet. 95 2. Addressing Models 97 The key of addressing model is the address block between Customer 98 Premises Equipment (CPE) and Carrier Grade NAT (CGN) 99 [I-D.ietf-behave-lsn-requirements]. It's mentioned in this section. 100 The best addressing model is "ISP Shared Address" which is defined in 101 [I-D.shirasaki-isp-shared-addr] and briefly described in this 102 section. 104 2.1. Global Address 106 ISP cannot assign IPv4 Global Address any more after the exhaustion. 108 2.2. Private Address 110 It has two major problems. 112 2.2.1. Policy Based Routing Issue 114 If both source and destination address of the packet are inside CGN, 115 it has to go through CGN. The reason is that some servers reject 116 receiving packets when the source address of receiving packet is 117 Private Address. Therefore packets have to go through the CGN for 118 rewriting the source address from Private Address to Global Address. 119 Additionally, if Private Address and Global Address co-exist inside 120 CGN, the ISP has to use Policy Based Routing (PBR). 122 2.2.2. Address Block Duplication Issue 124 The Private Address in ISP's network could conflict with its 125 customer's network address. Many CPEs between customer's network and 126 ISP's network cannot route the packet under this situation. To avoid 127 this, ISP has to negotiate with its all customers not to use the 128 reserved Private Address block. 130 2.2.3. Class-E Address (240/4) 132 It is known that some equipment such as routers and servers reject 133 packets from or to this address block. So, to use this address block 134 in ISP's network, ISP has to request its customers to replace their 135 equipment. In addition to that, ISP might have to replace their 136 equipment when it doesn't handle Class-E address packets properly. 138 2.2.4. ISP Shared Address 140 ISP Shared Address is the newly defined IPv4 address block that is to 141 be allocated from IANA free pool. It doesn't have any problem. 142 Spending some blocks from the exhausting IANA free pool could be 143 regarded as a problem, but from long view, this problem is much 144 smaller than its great merit. ISP Shared Address is defined in 145 [I-D.shirasaki-isp-shared-addr]. 147 3. Example Architectures 149 This section explains example architectures how to design NAT444 with 150 ISP Shared Address. 152 3.1. Direct Routing inside CGN 154 This architecture enables direct communication between customers 155 inside same CGN. It has the following advantages. 157 o The packets don't go through CGN. (No hairpining) 159 o The customers inside CGN can use bidirectional applications (e.g. 160 TV Conference, VPN). 162 o No need to use Policy Based Routing. 164 (The IPv4 Internet) 165 | Global Address 166 +----+----+ 167 | CGN | 168 +----+----+ 169 | 170 ISP Shared +-----------+----------+ ISP Shared 171 Address | .......... | Address 172 +----+----+ : : +----+----+ 173 | CPE NAT | : : | CPE NAT | 174 +----+----+ : : +----+----+ 175 Private | : : | Private 176 Address | v v | Address 177 +----+----+ +----+----+ 178 |IPv4 Host| |IPv4 Host| 179 +---------+ +---------+ 181 3.2. CGN Bypassing 183 This architecture is bypassing the NAT function of CGN. It has the 184 following advantage. 186 o The customers inside an ISP can use bidirectional applications 187 (e.g. TV Conference, VPN). 189 o Any communication in single ISP doesn't consume CGN external port. 191 o ISP's servers outside CGN can access CPE. (e.g. ICMP echo, SNMP, 192 remote access) 194 o ISP's servers outside CGN can distinguish which customer's 195 connection it receives. (e.g. DNS, Mail) 197 (The IPv4 Internet) 198 | 199 | +--------+ Network Monitor 200 | | Server | (ICMP echo, SNMP) 201 | +----+---+ DNS, Mail, Web, etc 202 Global | | ^ 203 Address +----------------------+ : 204 | .................... 205 | . : | 206 +----+----+ : : +----+----+ bypass NAT: 207 | CGN | : bypass : | CGN | Dst=ISP's Global Address 208 +----+----+ : NAT : +----+----+ or ISP Shared Address 209 ISP Shared | : : | 210 Address | : : | ISP Shared Address 211 +----+----+ : : +----+----+ 212 | CPE NAT | : : | CPE NAT | 213 +----+----+ : : +----+----+ 214 Private | : : | Private 215 Address | v v | Address 216 +----+----+ +----+----+ 217 |IPv4 Host| |IPv4 Host| 218 +---------+ +---------+ 220 3.3. Global Address Customers inside CGN 222 This architecture enables co-existing Global Address and ISP Shared 223 Address inside CGN. 225 It enables direct communications from ISP Shared Address customer to 226 Global Address customer inside same CGN. It has the following 227 advantage. 229 o The ISP can put ISP Shared Address customer and Global Address 230 customer in the same concentrator. 232 o The customers inside CGN can use bidirectional applications (e.g. 233 TV Conference, VPN). 235 o No need to use Policy Based Routing. 237 (The IPv4 Internet) 238 | 239 | Global Address 240 +----+----+ 241 | CGN | bypass NAT: Src/Dst=Global Address 242 +----+----+ 243 | Global Address and ISP Shared Address co-existing 244 +----------------------+ 245 | ......... | 246 +----+----+ : : +----+----+ 247 | Firewall| : : | CPE NAT | 248 +----+----+ : : +----+----+ 249 Global | : : | Private 250 Address | v : | Address 251 +-----+-----+ +----+----+ 252 |IPv4 Server| |IPv4 Host| 253 +-----------+ +---------+ 255 4. Acknowledgements 257 Thanks for the input and review by Shirou Niinobe, Takeshi Tomochika, 258 Tomohiro Fujisaki, Dai Nishino, JP address community members, AP 259 address community members and JPNIC members. 261 5. IANA Considerations 263 IANA is to allocate a certain size of address block from IANA free 264 pool. The size of it is described in [I-D.shirasaki-isp-shared-addr] 266 6. Security Considerations 268 There are no security considerations. 270 7. Normative References 272 [I-D.shirasaki-isp-shared-addr] 273 Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., 274 and H. Ashida, "ISP Shared Address", 275 draft-shirasaki-isp-shared-addr-07 (work in progress), 276 January 2012. 278 [I-D.ietf-behave-lsn-requirements] 279 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 280 and H. Ashida, "Common requirements for Carrier Grade NATs 281 (CGNs)", draft-ietf-behave-lsn-requirements-07 (work in 282 progress), June 2012. 284 [I-D.shirasaki-nat444] 285 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 286 and H. Ashida, "NAT444", draft-shirasaki-nat444-05 (work 287 in progress), January 2012. 289 Authors' Addresses 291 Jiro Yamaguchi 292 Fiber 26 Network Inc. 293 Haraguchi bldg., 5F, 3-11-4 Kanda Jinbo-cho, Chiyoda-ku 294 Tokyo 101-0051 295 Japan 297 Phone: +81 50 3463 6109 298 Email: jiro-y@f26n.jp 299 Yasuhiro Shirasaki 300 NTT Communications Corporation 301 NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku 302 Tokyo 100-8019 303 Japan 305 Phone: +81 3 6700 8530 306 Email: yasuhiro@nttv6.jp 308 Shin Miyakawa 309 NTT Communications Corporation 310 Granpark Tower 17F, 3-4-1 Shibaura, Minato-ku 311 Tokyo 108-8118 312 Japan 314 Phone: +81 3 6733 8671 315 Email: miyakawa@nttv6.jp 317 Akira Nakagawa 318 Japan Internet Exchange Co., Ltd. (JPIX) 319 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 320 Tokyo 100-0004 321 Japan 323 Phone: +81 90 9242 2717 324 Email: a-nakagawa@jpix.ad.jp 326 Hiroyuki Ashida 327 IS Consulting G.K. 328 12-17 Odenma-cho, Nihonbashi, Chuo-ku 329 Tokyo 103-0011 330 Japan 332 Email: assie@hir.jp