Internet Engineering Task Force Y. Shirasaki, Ed. Internet-Draft S. Miyakawa Expires: December 11, 2008 NTT Communications A. Nakagawa KDDI CORPORATION J. Yamaguchi IIJ H. Ashida iTSCOM June 9, 2008 ISP Shared Address after IPv4 Address Exhaustion draft-shirasaki-isp-shared-addr-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 11, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines IPv4 "ISP Shared Address" to be jointly used among Internet Service Providers. This space is intended to enable Shirasaki, et al. Expires December 11, 2008 [Page 1] Internet-Draft ISP Shared Address June 2008 Internet Service Providers' continuous IPv4 based operation even after the IPv4 address exhaustion. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Solutions Using Existing Technology . . . . . . . . . . . . . 3 5.1. IPv6 to IPv4 Translator . . . . . . . . . . . . . . . . . 3 5.2. RFC1918 to IPv6 to IPv4 NAT . . . . . . . . . . . . . . . 3 5.3. RFC1918 to RFC1918 to IPv4 NAT . . . . . . . . . . . . . . 4 5.4. RFC1918 to IPv4 to IPv4 NAT . . . . . . . . . . . . . . . 4 6. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. Advantages of This Proposal . . . . . . . . . . . . . . . . . 5 8. Rationale behind the Proposal . . . . . . . . . . . . . . . . 5 9. Possible Issues . . . . . . . . . . . . . . . . . . . . . . . 6 10. Operational Recommendation . . . . . . . . . . . . . . . . . . 6 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 13. Security Considerations . . . . . . . . . . . . . . . . . . . 6 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 14.1. Normative References . . . . . . . . . . . . . . . . . . . 7 14.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. FAQ . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Shirasaki, et al. Expires December 11, 2008 [Page 2] Internet-Draft ISP Shared Address June 2008 1. Introduction The current model [EXHA] shows that global IPv4 addresses from the IANA pool will run out in a few years. This document is proposed to prepare for the IPv4 address exhaustion. NOT to expand private address space [RFC1918]. 2. Prerequisite It assumes an environment where end-users use RFC1918 address behind Customer Premises Equipment (CPE). The servers that have ONLY IPv4 address will continue to exist even after the IPv4 address exhaustion. However, ISPs cannot assign additional global IPv4 addresses to its end-users in order to access such servers. 3. Problem End-users without any global IPv4 address space will not be able to access to the IPv4 Internet after the IPv4 address exhaustion. 4. Goal The goal is to allow the end-users who don't have global IPv4 address to access to the IPv4-only servers without having to replace their equipments. 5. Solutions Using Existing Technology The following solutions using existing technology cannot achieve the goal mentioned above. 5.1. IPv6 to IPv4 Translator This solution has two problems. Firstly, some end-users still use PCs or LAN equipment that doesn't support IPv6. They cannot use IPv6. Secondly, some web hyperlinks have the numeric IPv4 address notation in URL. PCs having only IPv6 address cannot follow such hyperlinks. 5.2. RFC1918 to IPv6 to IPv4 NAT This model is described in [I-D.durand-v6ops-natv4v6v4]. Under this model, ISPs must request end-users to replace the CPE, which is end- users' property. Furthermore, the replaced CPE must be "NATV4V6V4 Shirasaki, et al. Expires December 11, 2008 [Page 3] Internet-Draft ISP Shared Address June 2008 capable" CPE, which is currently not readily available on the market. Even if "NATV4V6V4 capable" CPE will be available in the future, it is practically impossible for ISPs to make all their end-users replace their equipment. 5.3. RFC1918 to RFC1918 to IPv4 NAT In this model, ISP assigns RFC1918 address to new end-users. ISPs provide the internet connectivity to such end-users using Career Grade NAT (CGN). This solution has two problems. Firstly, end- user's WAN (assigned by ISP) and LAN addresses may conflict. In such situation, end-users may have to renumber their address. Secondly, some firewalls/servers reject packets with RFC1918 address as its source address for security reasons, therefore, end-users will not be able to access servers behind the same CGN. 5.4. RFC1918 to IPv4 to IPv4 NAT In this mode, ISP requests a certain size of global IPv4 address space before the IPv4 address exhaustion to share the same range between a set of regions/areas within their infrastructure. However, this solution has some problems. Firstly, IPv4 global address will not be used efficiently compared to other solutions as it requires address space to be distributed for each ISP's infrastructure. Secondly, since an end-user's IPv4 address is not unique within ISP's infrastructure, it is difficult for ISP operators to confirm reachability to a specific user by sending packets, such as ICMP echo. Finally, the region may be fragmented to small pieces if ISP has only small blocks available for this purpose. 6. Proposal This proposal defines "ISP Shared Address" to be jointly used among ISPs. It is intended to be assigned between CPE and CGN. This space must not to be advertised to the Internet. The size of the address space is TBD. Following table shows the coverage by size of ISP shared address. Shirasaki, et al. Expires December 11, 2008 [Page 4] Internet-Draft ISP Shared Address June 2008 +------+--------------+ | Size | ISP Coverage | +------+--------------+ | /10 | 49% | | /9 | 58% | | /8 | 69% | | /7 | 85% | | /6 | 96% | | /5 | 100% | +------+--------------+ ISP coverage is the ratio of numbers of hosts on the Internet to numbers of hosts in the ISP which is covered by the size of ISP shared address as of June in 2008. Table 1: Coverage by Size of ISP Shared Address 7. Advantages of This Proposal Defining this address space enables ISPs to continue expanding their service without requesting end-users to replace or renumber their LAN equipment after IPv4 address exhaustion. Moreover, it overcomes problems described in section 5 such as: o It supports "IPv4-only" equipment in end-users' network (problem in Section 5.1) o End-users' WAN and LAN addresses do not conflict (problem in Section 5.3) o End-users are able to access to servers behind the same CGN (problem in Section 5.3) o It is possible for ISP operators to send packets to a specific end-user (problem in Section 5.4) 8. Rationale behind the Proposal The rationale to be used by only ISPs: - To avoid address conflicts between end-users' WAN (assigned by ISPs) and LAN addresses The rationale not to use 240/4: - Many CPEs, routers, servers and other nodes cannot handle 240/4. The rationale to prohibit advertising this address space: Shirasaki, et al. Expires December 11, 2008 [Page 5] Internet-Draft ISP Shared Address June 2008 - Many ISPs will use this same space. The rationale to prohibit querying for reverse DNS to root DNS: - Many ISPs will use this same space. 9. Possible Issues - Global prefix(es) will be consumed. However, it provides more benefit by providing ISPs with an option to continue IPv4 based operations even after the IPv4 address exhaustion. - Some applications used by end users won't work in the Double-NAT network. However, providing end-users with an option to access to the IPv4 Internet with some limitations, is more preferable than providing no access to the IPv4 Internet after the IPv4 address exhaustion. 10. Operational Recommendation This address space must not be used at IXs. Reverse DNS queries for this address space must not be sent to root DNS servers. 11. 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. 12. IANA Considerations IANA is to record the allocation of the IPv4 global unicast address prefix TBD as an ISPs Shared use prefix in the IPv4 address registry. 13. Security Considerations ISPs should prevent packets to be sent out from its network with this space as source and/or destination address. 14. References Shirasaki, et al. Expires December 11, 2008 [Page 6] Internet-Draft ISP Shared Address June 2008 14.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [EXHA] Huston, G., "IPv4 Address Report", . [I-D.durand-v6ops-natv4v6v4] Durand, A., "Distributed NAT for broadband deployments post IPv4 exhaustion", draft-durand-v6ops-natv4v6v4-01 (work in progress), February 2008. [I-D.wilson-class-e] Wilson, P., "Redesignation of 240/4 from "Future Use" to "Limited Use for Large Private Internets"", draft-wilson-class-e-01 (work in progress), August 2007. 14.2. Informative References [PROP58] Niinobe, S., Tomochika, T., Yamaguchi, J., Nishino, D., Ashida, H., Nakagawa, A., and T. Hosaka, "Proposal to create IPv4 shared use address space among LIRs", 2008, . Appendix A. FAQ Q1. Will this address space be used even if it requires large-scale renewal/renumbering of a network? A1. Yes, some people expressed their plan to use it in their network in APNIC Open Policy Meeting as well as in JPNIC Open Policy Meeting. Q2. Is this proposal intended to delay the date of IPv4 address exhaustion? A2. No. It is intended to address issues after the IPv4 address exhaustion. Q3. Is it possible to use this space instead of RFC1918 address in private network? A3. No. Since it creates address conflicts between end-user's WAN (this space assigned by ISP) and LAN. Q4. In case of M&A between ISPs using Shared Address, what happens ? A4. Address conflict may happen. It is out of scope. Shirasaki, et al. Expires December 11, 2008 [Page 7] Internet-Draft ISP Shared Address June 2008 Q5. Is this proposal different from [I-D.wilson-class-e]? A5. Yes. It is not intended to expand RFC1918 address. Furtheremore, it does not consider 240/4 as usable address for this purpose. Authors' Addresses Yasuhiro Shirasaki (editor) 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 Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Phone: +81 3 6800 3262 Email: miyakawa@nttv6.jp Akira Nakagawa KDDI CORPORATION GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku Tokyo 102-8460 Japan Email: ai-nakagawa@kddi.com Jiro Yamaguchi Internet Initiative Japan Inc. Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho, Chiyoda-ku Tokyo 101-0051 Japan Phone: +81 3 5205 6500 Email: jiro-y@iij.ad.jp Shirasaki, et al. Expires December 11, 2008 [Page 8] Internet-Draft ISP Shared Address June 2008 Hiroyuki Ashida its communications Inc. 3-5-7 Hisamoto Takatsu-ku Kawasaki-shi Kanagawa 213-0011 Japan Email: ashida@itscom.ad.jp Shirasaki, et al. Expires December 11, 2008 [Page 9] Internet-Draft ISP Shared Address June 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Shirasaki, et al. Expires December 11, 2008 [Page 10]