Important: IPv4 Future Allocation Concept RFC

Joe Greco jgreco at ns.sol.net
Thu Apr 1 22:41:34 UTC 2010


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