Internet Engineering Task Force J. Yamaguchi Internet-Draft Fiber 26 Network Intended status: Informational Y. Shirasaki Expires: January 6, 2013 S. Miyakawa NTT Communications A. Nakagawa Japan Internet Exchange (JPIX) H. Ashida IS Consulting G.K. July 5, 2012 NAT444 addressing models draft-shirasaki-nat444-isp-shared-addr-08 Abstract This document describes addressing models of NAT444. There are some addressing models of NAT444. The addressing models have some issues of network behaviors, operations, and addressing. This document helps network architects to use NAT444 after IPv4 address exhaustion. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 6, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Yamaguchi, et al. Expires January 6, 2013 [Page 1] Internet-Draft NAT444 addressing models July 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Yamaguchi, et al. Expires January 6, 2013 [Page 2] Internet-Draft NAT444 addressing models July 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Addressing Models . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Global Address . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Private Address . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Policy Based Routing Issue . . . . . . . . . . . . . . 4 2.2.2. Address Block Duplication Issue . . . . . . . . . . . . 4 2.2.3. Class-E Address (240/4) . . . . . . . . . . . . . . . . 4 2.2.4. ISP Shared Address . . . . . . . . . . . . . . . . . . 5 3. Example Architectures . . . . . . . . . . . . . . . . . . . . . 5 3.1. Direct Routing inside CGN . . . . . . . . . . . . . . . . . 5 3.2. CGN Bypassing . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Global Address Customers inside CGN . . . . . . . . . . . . 7 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Yamaguchi, et al. Expires January 6, 2013 [Page 3] Internet-Draft NAT444 addressing models July 2012 1. Introduction NAT444 [I-D.shirasaki-nat444] is one of solutions after IPv4 address exhaustion. ISP can select some addressing models of NAT444. The addressing models have some issues of network behaviors, operations, and addressing. This document describes these issues and solutions. It boosts up to deploy the IPv6 Internet. 2. Addressing Models The key of addressing model is the address block between Customer Premises Equipment (CPE) and Carrier Grade NAT (CGN) [I-D.ietf-behave-lsn-requirements]. It's mentioned in this section. The best addressing model is "ISP Shared Address" which is defined in [I-D.shirasaki-isp-shared-addr] and briefly described in this section. 2.1. Global Address ISP cannot assign IPv4 Global Address any more after the exhaustion. 2.2. Private Address It has two major problems. 2.2.1. Policy Based Routing Issue If both source and destination address of the packet are inside CGN, it has to go through CGN. The reason is that some servers reject receiving packets when the source address of receiving packet is Private Address. Therefore packets have to go through the CGN for rewriting the source address from Private Address to Global Address. Additionally, if Private Address and Global Address co-exist inside CGN, the ISP has to use Policy Based Routing (PBR). 2.2.2. Address Block Duplication Issue The Private Address in ISP's network could conflict with its customer's network address. Many CPEs between customer's network and ISP's network cannot route the packet under this situation. To avoid this, ISP has to negotiate with its all customers not to use the reserved Private Address block. 2.2.3. Class-E Address (240/4) It is known that some equipment such as routers and servers reject packets from or to this address block. So, to use this address block Yamaguchi, et al. Expires January 6, 2013 [Page 4] Internet-Draft NAT444 addressing models July 2012 in ISP's network, ISP has to request its customers to replace their equipment. In addition to that, ISP might have to replace their equipment when it doesn't handle Class-E address packets properly. 2.2.4. ISP Shared Address ISP Shared Address is the newly defined IPv4 address block that is to be allocated from IANA free pool. It doesn't have any problem. Spending some blocks from the exhausting IANA free pool could be regarded as a problem, but from long view, this problem is much smaller than its great merit. ISP Shared Address is defined in [I-D.shirasaki-isp-shared-addr]. 3. Example Architectures This section explains example architectures how to design NAT444 with ISP Shared Address. 3.1. Direct Routing inside CGN This architecture enables direct communication between customers inside same CGN. It has the following advantages. o The packets don't go through CGN. (No hairpining) o The customers inside CGN can use bidirectional applications (e.g. TV Conference, VPN). o No need to use Policy Based Routing. (The IPv4 Internet) | Global Address +----+----+ | CGN | +----+----+ | ISP Shared +-----------+----------+ ISP Shared Address | .......... | Address +----+----+ : : +----+----+ | CPE NAT | : : | CPE NAT | +----+----+ : : +----+----+ Private | : : | Private Address | v v | Address +----+----+ +----+----+ |IPv4 Host| |IPv4 Host| +---------+ +---------+ Yamaguchi, et al. Expires January 6, 2013 [Page 5] Internet-Draft NAT444 addressing models July 2012 3.2. CGN Bypassing This architecture is bypassing the NAT function of CGN. It has the following advantage. o The customers inside an ISP can use bidirectional applications (e.g. TV Conference, VPN). o Any communication in single ISP doesn't consume CGN external port. o ISP's servers outside CGN can access CPE. (e.g. ICMP echo, SNMP, remote access) o ISP's servers outside CGN can distinguish which customer's connection it receives. (e.g. DNS, Mail) (The IPv4 Internet) | | +--------+ Network Monitor | | Server | (ICMP echo, SNMP) | +----+---+ DNS, Mail, Web, etc Global | | ^ Address +----------------------+ : | .................... | . : | +----+----+ : : +----+----+ bypass NAT: | CGN | : bypass : | CGN | Dst=ISP's Global Address +----+----+ : NAT : +----+----+ or ISP Shared Address ISP Shared | : : | Address | : : | ISP Shared Address +----+----+ : : +----+----+ | CPE NAT | : : | CPE NAT | +----+----+ : : +----+----+ Private | : : | Private Address | v v | Address +----+----+ +----+----+ |IPv4 Host| |IPv4 Host| +---------+ +---------+ Yamaguchi, et al. Expires January 6, 2013 [Page 6] Internet-Draft NAT444 addressing models July 2012 3.3. Global Address Customers inside CGN This architecture enables co-existing Global Address and ISP Shared Address inside CGN. It enables direct communications from ISP Shared Address customer to Global Address customer inside same CGN. It has the following advantage. o The ISP can put ISP Shared Address customer and Global Address customer in the same concentrator. o The customers inside CGN can use bidirectional applications (e.g. TV Conference, VPN). o No need to use Policy Based Routing. (The IPv4 Internet) | | Global Address +----+----+ | CGN | bypass NAT: Src/Dst=Global Address +----+----+ | Global Address and ISP Shared Address co-existing +----------------------+ | ......... | +----+----+ : : +----+----+ | Firewall| : : | CPE NAT | +----+----+ : : +----+----+ Global | : : | Private Address | v : | Address +-----+-----+ +----+----+ |IPv4 Server| |IPv4 Host| +-----------+ +---------+ 4. Acknowledgements Thanks for the input and review by Shirou Niinobe, Takeshi Tomochika, Tomohiro Fujisaki, Dai Nishino, JP address community members, AP address community members and JPNIC members. Yamaguchi, et al. Expires January 6, 2013 [Page 7] Internet-Draft NAT444 addressing models July 2012 5. IANA Considerations IANA is to allocate a certain size of address block from IANA free pool. The size of it is described in [I-D.shirasaki-isp-shared-addr] 6. Security Considerations There are no security considerations. 7. Normative References [I-D.shirasaki-isp-shared-addr] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "ISP Shared Address", draft-shirasaki-isp-shared-addr-07 (work in progress), January 2012. [I-D.ietf-behave-lsn-requirements] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for Carrier Grade NATs (CGNs)", draft-ietf-behave-lsn-requirements-07 (work in progress), June 2012. [I-D.shirasaki-nat444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", draft-shirasaki-nat444-05 (work in progress), January 2012. Authors' Addresses Jiro Yamaguchi Fiber 26 Network Inc. Haraguchi bldg., 5F, 3-11-4 Kanda Jinbo-cho, Chiyoda-ku Tokyo 101-0051 Japan Phone: +81 50 3463 6109 Email: jiro-y@f26n.jp Yamaguchi, et al. Expires January 6, 2013 [Page 8] Internet-Draft NAT444 addressing models July 2012 Yasuhiro Shirasaki NTT Communications Corporation NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Japan Phone: +81 3 6700 8530 Email: yasuhiro@nttv6.jp Shin Miyakawa NTT Communications Corporation Granpark Tower 17F, 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Phone: +81 3 6733 8671 Email: miyakawa@nttv6.jp Akira Nakagawa Japan Internet Exchange Co., Ltd. (JPIX) Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku Tokyo 100-0004 Japan Phone: +81 90 9242 2717 Email: a-nakagawa@jpix.ad.jp Hiroyuki Ashida IS Consulting G.K. 12-17 Odenma-cho, Nihonbashi, Chuo-ku Tokyo 103-0011 Japan Email: assie@hir.jp Yamaguchi, et al. Expires January 6, 2013 [Page 9]