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",
<http://ipv4.potaroo.net>.
[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,
<http://www.apnic.net/policy/proposals/
prop-058-v001.html>.
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]