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@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@ietf.org. Greco, Joe Expires March 2011 FORMFEED[Page 7]
That is the best thing I've seen today. Kudos to whoever wrote that. :) -----Original Message----- From: Joe Greco [mailto:jgreco@ns.sol.net] Sent: Thursday, April 01, 2010 3:42 PM To: nanog@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@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@ietf.org. Greco, Joe Expires March 2011 FORMFEED[Page 7]
At 06:41 PM 4/1/2010, Joe Greco wrote: Ok, this is weird. I had suggested almost exactly this same scheme to someone else earlier today. When did you put the bug in my office? Greg D. Moore President mooregr@greenms.com Ask me about lily, an RPI based chat system: http://lilycore.sourceforge.net/ Help honor our WWII Veterans: http://www.honorflight.org/
On Thu, Apr 1, 2010 at 6:41 PM, Joe Greco <jgreco@ns.sol.net> wrote:
Someone suggested this be posted more visibly.
Joe, Been there, done that: http://bill.herrin.us/network/ipxl.html Maybe the humor was too subtle... -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
participants (6)
-
Antonio Querubin -
Greg D. Moore -
Jim Burwell -
Joe Greco -
Thomas Magill -
William Herrin