Important: IPv4 Future Allocation Concept RFC
Thomas Magill
tmagill at providecommerce.com
Thu Apr 1 23:02:03 UTC 2010
That is the best thing I've seen today. Kudos to whoever wrote that. :)
-----Original Message-----
From: Joe Greco [mailto:jgreco at ns.sol.net]
Sent: Thursday, April 01, 2010 3:42 PM
To: nanog at nanog.org
Subject: Important: IPv4 Future Allocation Concept RFC
Someone suggested this be posted more visibly.
... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI -
http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and]
then I
won't contact you again." - Direct Marketing Ass'n position on e-mail
spam(CNN)
With 24 million small businesses in the US alone, that's way too many
apples.
Network Working Group Joe Greco
Request for Comments: [nnnn] sol.net Network Services
Category: Experimental April 1, 2010
Expires March 2011
IPv4 Future Allocation Is Limited Unless Registries Expand
Status of this Memo
Distribution of this memo is unlimited.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The momentum of the currently deployed IPv4 network has resulted
in a slower transition to IPv6 than expected, and IPv4 address
reserves may soon be exhausted. This memo defines an additional
class of IPv4 space which may be deployed as an interim solution.
Greco, Joe Expires March 2011 FORMFEED[Page 1]
Internet Draft IPv4 Class F Space April 1, 2010
Table of Contents
1. Introduction ....................................................2
2. Classful Addressing .............................................2
2.1. Expansion via Classful Addressing ..........................3
2.2. Impact on existing infrastructure ..........................3
2.3. Negative aspects to extending IPv4 lifetime ................4
2.4. Positive aspects to extending IPv4 lifetime ................4
2.5. Adjusted estimated IPv4 depletion date .....................4
2.6. Impact on IPv6 adoption ....................................4
3. Security Considerations .........................................5
4. IANA Considerations .............................................5
5. References ......................................................5
5.1. Informative References .....................................5
5.2. Acknowledgements ...........................................5
1. Introduction
The current Internet addressing scheme has been reasonably successful
at providing an Internet capable of providing network services to
users. However, because of massive growth and the increasing number
of networks being connected to the Internet, an ongoing shortage of
network numbers has brought us close to the point where assignable
IPv4 prefixes are exhausted. To combat this, the Internet is
currently undergoing a major transition to IPv6. Despite the looming
exhaustion of IPv4 space [IPv4_Report], IPv6 adoption rates have been
slower than expected. Policy suggestions to extend the availability
of IPv4 have ranged from reclamation of unused legacy IPv4
delegations [ICANN_feb08] to the use of carrier-grade NAT to place
most customers of service providers on RFC1918 space [Nishitani].
We propose a different solution to the problem.
RFC 1365 [RFC1365] and RFC 1375 [RFC1375] suggest some possible
methods for implementing additional address classes. While classful
addressing is now considered obsolete, the use of class to refer to a
particular portion of the IPv4 address space is still useful for that
purpose. Allocations within this space are expected to conform to
existing CIDR allocation guidelines. By allocating an additional
class, we gain a substantial amount of IP space.
Greco, Joe Expires March 2011 FORMFEED[Page 2]
Internet Draft IPv4 Class F Space April 1, 2010
2. Classful Addressing
Classful addressing was introduced in RFC 791 [RFC791], providing
Class A, B, and C spaces. RFC 1700 [RFC1700] defines Class D and E,
and we derive the resulting table:
Leading Network
Class Bits Bits Range
------ ------- ------- -----
A 0 8 .0.n.n.n-127.n.n.n
B 10 16 128.n.n.n-191.n.n.n
C 110 24 192.n.n.n-223.n.n.n
D 1110 undef 224.n.n.n-239.n.n.n
E 1111 undef 240.n.n.n-255.n.n.n
2.1. Expansion via Classful Addressing
While classful routing is generally no longer relevant, it provides
us with a useful clue about how to proceed. The prepending of a new
leading bit provides access to additional IP space, and so it would
seem to be a reasonable short-term fix to define a new class, Class
F, giving us:
Leading Network
Class Bits Bits Range
------ ------- ------- -----
A 0 8 0.n.n.n-127.n.n.n
B 10 16 128.n.n.n-191.n.n.n
C 110 24 192.n.n.n-223.n.n.n
D 1110 undef 224.n.n.n-239.n.n.n
E 1111 undef 240.n.n.n-255.n.n.n
F 10000 undef 256.n.n.n-511.n.n.n
This theoretically offers up to a few hundred more /8 assignments
that IANA would delegate to registries as an interim solution.
2.2. Impact on existing infrastructure
Currently deployed equipment may not be able to cope with an expanded
range within the first octet. In particular, a router might fail to
observe the additional leading bit. Such a scenario would
effectively map network 257/8 into 1/8 on that device. Such a
limitation can be carefully worked around through an allocation
strategy that avoids currently occupied space in the Class A through
C spaces. For example, 1/8 and 5/8 are currently IANA reserved
space, 7/8 is assigned to DoD, and other various networks are
unrouted or unoccupied as well. This suggests that 261/8 and 263/8
would be good targets for immediate allocation.
Greco, Joe Expires March 2011 FORMFEED[Page 3]
Internet Draft IPv4 Class F Space April 1, 2010
2.3. Negative aspects to extending IPv4 lifetime
IPv4 lifetime estimates have frequently been incorrect. This has
been one factor that had led to sluggish momentum in adopting IPv6,
and has not generated sufficient urgency to move from IPv4 to IPv6.
Artificially extending IPv4's available space with this proposal
would be likely to slow IPv6 adoption rates, at least somewhat, as
many decision makers would interpret the expansion of the IPv4 free
pool as a compelling reason to avoid unnecessary near-term investment
in migration to IPv6.
2.4. Positive aspects to extending IPv4 lifetime
The cost of upgrading or replacing many networking devices globally
is extremely high. A quick survey of contemporary networking devices
suggests that even many current devices are incapable of supporting
IPv6. The world is clearly not entirely ready for IPv6, and
therefore IPv4 can be expected to be a requirement for many more
years.
Further, IPv6 renders it almost impossible to memorize IP addresses,
which places undue burden on network engineers and analysts. Setting
up a newly configured device virtually demands a cut-and-paste
capable interface under IPv6.
Finally, IPv6 is designed to waste a few billion v4 Internets worth
of IP addresses for every autoconfigured ethernet. There are
virtually endless IP addresses that will never be used, and the
untapped potential wasted by IPv6 is depressing. IPv4, on the other
hand, will ultimately be pushed to its technical limits, with triple-
NAT becoming commonplace as service providers seek to optimize
available space. This will be very exciting and will also help to
keep network engineers gainfully employed.
2.5. Adjusted estimated IPv4 depletion date
The current RIR allocation rate is approximately 12 /8's per year.
This rate has grown slowly over time, and is estimated to be at least
20 /8's within five years. Extrapolation using conservative
estimates suggests that Class F space would be exhausted around April
1st, 2020.
2.6. Impact on IPv6 adoption
There has been much concern expressed about the slow adoption rate of
IPv6. In a situation where IPv4 space was nearly depleted, the slow
rate would be of great concern. However, by implementing Class F
space as outlined in this document, it should be clear that depletion
Greco, Joe Expires March 2011 FORMFEED[Page 4]
Internet Draft IPv4 Class F Space April 1, 2010
need not be imminent, and in 2020, when there are finally 5,000
routes in the IPv6 table and Class F space is depleted, another
clever solution will need to be devised.
3. Security Considerations
There are no security considerations relevant to this document.
4. IANA Considerations
No actions are required from IANA as result of the publication of
this document. Implementation of the proposal contained herein may
require some action, however.
5. References
5.1. Informative References
[IPv4_Report] Huston, G., "IPv4 Address Report", 2009,
<http://www.potaroo.net/tools/ipv4/index.html>.
[ICANN_feb08] ICANN, "ICANN Recovers Large Block of Internet Address
Space", February 2008,
<http://www.icann.org/en/announcements/announcement-2-10feb08.htm>.
[Nishitani] Nishitani, T., Yamagata, I., et. al., "Common Functions
of Large Scale NAT", draft-nishitani-cgn-03.
[RFC791] Information Sciences Institute, USC, "DARPA Internet Program
Protocol Specification", RFC 791, September 1981.
[RFC1365] Siyan, K., "An IP Address Extension Proposal", RFC 1365,
September 1992.
[RFC1375] Robinson, P., "Suggestion for New Classes of IP Addresses",
RFC 1375, October 1992.
[RFC1700] Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700,
October 1994.
5.2. Acknowledgements
The author would like to offer a special note of thanks to Robert E.
Seastrom <rs at seastrom.com> for pointing out that this would be
Class F space.
Greco, Joe Expires March 2011 FORMFEED[Page 5]
Internet Draft IPv4 Class F Space April 1, 2010
Authors' Addresses
Joe Greco
sol.net Network Services
P.O. Box 16
Milwaukee, WI 53201-0016
Phone: +1-888-830-2216
URI: http://www.sol.net/~jgreco
EMail: rfc-apr1 at 4ac18e35.biz.jgreco.net
Greco, Joe Expires March 2011 FORMFEED[Page 6]
Internet Draft IPv4 Class F Space April 1, 2010
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
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 at ietf.org.
Greco, Joe Expires March 2011 FORMFEED[Page 7]
More information about the NANOG
mailing list