Re: The Reg does 240/4
Christopher Hawker <[email protected]> Tue, 13 Feb 2024 10:03:55 +0000
| Newsgroups | gmane.org.operators.nanog,gmane.org.operators.ausnog,gmane.org.operators.sanog |
|---|---|
| Message-ID | <SYBP282MB05387ACE2E155E6779A0EDD1CC4F2@SYBP282MB0538.AUSP282.PROD.OUTLOOK.COM> |
--_000_SYBP282MB05387ACE2E155E6779A0EDD1CC4F2SYBP282MB0538AUSP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, [Note: I have cross-posted this reply to a thread from NANOG on AusNOG, SAN= OG and APNIC-Talk in order to invite more peers to engage in the discussion= on their respective forums.] Just to shed some light on the article and our involvement... Since September 1981, 240/4 has been reserved for future use, see https://w= ww.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml. This s= pace has always been reserved for future use and given the global shortage = of available space for new network operators we feel it is appropriate for = this space to be reclassified as Unicast space available for delegation by = IANA/PTI to RIRs on behalf of ICANN. At present, the IP space currently available for RIRs to delegate to new me= mbers is minimal, if any at all. The primary goal of our call for change is= to afford smaller players who are wanting to enter the industry the opport= unity to do so without having to shell out the big dollars for space. Altho= ugh I do not agree with IP space being treated as a commodity (as this was = not what it was intended to be), those who can afford to purchase space may= do so and those who cannot should be able to obtain space from their respe= ctive RIR without having to wait over a year in some cases just to obtain s= pace. It's not intended to flood the market with resources that can be sold= off to the highest bidder, and this can very well be a way for network ope= rators to plan to properly roll out IPv6. At this point in time, the uptake= and implementation of IPv6 is far too low (only 37% according to https://s= tats.labs.apnic.net/ipv6) for new networks to deploy IPv6 single-stack, mea= ning that we need to continue supporting IPv4 deployments. The reallocation of IPv4 space marked as Future Use would not restrict or i= nhibit the deployment of IPv6, if anything, in our view it will help the de= ployment through allowing these networks to service a greater number of cus= tomers than what a single /24 v4 prefix will allow. Entire regions of an ec= onomy have the potential to be serviced by a single /23 IPv4 prefix when us= ed in conjunction with IPv6 space. Now, some have argued that we should not do anything with IPv4 and simply l= et it die out. IPv4 will be around for the foreseeable future and while it = is, we need to allow new operators to continue deploying networks. It is un= fair of us to say "Let's all move towards IPv6 and just let IPv4 die" howev= er the reality of the situation is that while we continue to treat it as a = commodity and allow v6 uptake to progress as slowly as it is, we need to co= ntinue supporting it v4. Some have also argued that networks use this space= internally within their infrastructure. 240/4 was always marked as Reserve= d for Future Use and if network operators elect to squat on reserved space = instead of electing to deploy v6 across their internal networks then that i= s an issue they need to resolve, and it should not affect how it is realloc= ated. It goes against the bottom-up approach of policy development by allow= ing larger network operators to state that this space cannot be made unicas= t because they are using it internally (even though it's not listed in RFC1= 918), and its reallocation would affect their networks. In the APNIC region, there is a policy which only allows for a maximum of a= /23 IPv4 prefix to be allocated/assigned to new members and any more space= required must be acquired through other means. If (as an example) APNIC we= re to receive 3 x /8 prefixes from the 240/4 space this would allow for del= egations to be made for approximately the next ~50 years whereas if policy = was changed to allow for delegations up to and including a /22 this would e= xtend the current pool by well over 20 years, based on current exhaustion r= ates and allowing for pool levels to return to pre-2010 levels. Now, we know there's definitely going to be some pushback on this. This won= 't be easy to accomplish and it will take some time. However, if we do noth= ing then nothing will happen. The currently available pool has reached seve= re exhaustion levels yet we have a block representing about 6% of the total= possible IP space which may not seem like a lot yet it can go a long way. This call for change is not about making space available for existing netwo= rks. It is about new networks emerging into and on the internet. While we d= o work towards IPv6 being the primary addressing method we need to continue= allow those who may not be able to deploy IPv6 to connect to the internet. Regards, Christopher Hawker ________________________________ From: NANOG <[email protected]> on behalf of J= ay R. Ashworth <[email protected]> Sent: Tuesday, February 13, 2024 5:19 PM To: North American Operators' Group <[email protected]> Subject: The Reg does 240/4 I know we had a thread on this last month, but I can't remember what it was titled. ElReg has done a civilian-level backgrounder on the 240/4 issue, for anyone who wants to read and scoff at it. :-) https://www.theregister.com/2024/02/09/240_4_ipv4_block_activism/ Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.= com Designer The Things I Think RFC 2= 100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover = DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1= 274 --_000_SYBP282MB05387ACE2E155E6779A0EDD1CC4F2SYBP282MB0538AUSP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo= ttom:0;} </style> </head> <body dir=3D"ltr"> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Hello all,</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> [Note: I have cross-posted this reply to a thread from NANOG on AusNOG, SAN= OG and APNIC-Talk in order to invite more peers to engage in the discussion= on their respective forums.]</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> Just to shed some light on the article and our involvement...</div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">Since September 1981, 240/4 has been reserved fo= r future use, see <a href=3D"https://www.iana.org/assignments/ipv4-address-space/ipv4-address= -space.xhtml" id=3D"OWAbafe4be0-dfff-4c40-6c55-ec1c8931a4af" class=3D"OWAAu= toLink" data-loopstyle=3D"linkonly"> https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtm= l</a>. This space has always been reserved for future use and given the glo= bal shortage of available space for new network operators we feel it is app= ropriate for this space to be reclassified as Unicast space available for delegation by IANA/PTI to RIRs on behalf&nb= sp;of ICANN.</span></div> <div class=3D"elementToProof" style=3D"font-family: Aptos, Aptos_EmbeddedFo= nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; c= olor: rgb(0, 0, 0);"> <br> </div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">At present, the IP space currently available for= RIRs to delegate to new members is minimal, if any at all. The primary goal of our call for change is to affo= rd smaller players who are wanting to enter the industry the opportunity to= do so without having to shell out the big dollars for space. Although I do= not agree with IP space being treated as a commodity (as this was not what it was intended to be), those who can= afford to purchase space may do so and those who cannot should be able to = obtain space from their respective RIR without having to wait over a year i= n some cases just to obtain space. It's not intended to flood the market with resources that can be sold off = to the highest bidder, and this can very well be a way for network operator= s to plan to properly roll out IPv6. At this point in time, the uptake and = implementation of IPv6 is far too low (only 37% according to <a href=3D"https://stats.labs.apnic.net/ipv6" i= d=3D"LPlnk258986" class=3D"OWAAutoLink"> https://stats.labs.apnic.net/ipv6</a>) for new networks to deploy IPv6= single-stack, meaning that we need to continue supporting IPv4 deployments= .</span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);"><br> </span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">The reallocation of IPv4 space marked as Future = Use would not restrict or inhibit the deployment of IPv6, if anything, in our view it will help the deployment t= hrough allowing these networks to service a greater number of customers tha= n what a single /24 v4 prefix will allow. Entire regions of an economy have= the potential to be serviced by a single /23 IPv4 prefix when used in conjunction with IPv6 space.</span><= /div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);"><br> </span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">Now, some have argued that we should not do anyt= hing with IPv4 and simply let it die out. IPv4 will be around for the foreseeable future and while it is, = we need to allow new operators to continue deploying networks. It is unfair= of us to say "Let's all move towards IPv6 and just let IPv4 die"= however the reality of the situation is that while we continue to treat it as a commodity and allow v6 uptake to progress as = slowly as it is, we need to continue supporting it v4. Some have also argue= d that networks use this space internally within their infrastructure. 240/= 4 was always marked as Reserved for Future Use and if network operators elect to squat on reserved space i= nstead of electing to deploy v6 across their internal networks then that is= an issue they need to resolve, and it should not affect how it is realloca= ted. It goes against the bottom-up approach of policy development by allowing larger network operators to sta= te that this space cannot be made unicast because they are using it interna= lly (even though it's not listed in RFC1918), and its reallocation would af= fect their networks.</span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);"><br> </span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">In the APNIC region, there is a policy which onl= y allows for a maximum of a /23 IPv4 prefix to be allocated/assigned to new members and any more space required= must be acquired through other means. If (as an example) APNIC were to rec= eive 3 x /8 prefixes from the 240/4 space this would allow for delegations = to be made for approximately the next ~50 years whereas if policy was changed to allow for delegations up t= o and including a /22 this would extend the current pool by well over 20 ye= ars, based on current exhaustion rates and allowing for pool levels to retu= rn to pre-2010 levels.</span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);"><br> </span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">Now, we know there's definitely going to be some= pushback on this. This won't be easy to accomplish and it will take some time. However, if we do nothing then n= othing will happen. The currently available pool has reached severe exhaust= ion levels yet we have a block representing about 6% of the total possible = IP space which may not seem like a lot yet it can go a long way.</span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);"><br> </span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">This call for change is not about making space a= vailable for existing networks. It is about new networks emerging into and on the internet. While we do work tow= ards IPv6 being the primary addressing method we need to continue allow tho= se who may not be able to deploy IPv6 to connect to the internet.</span></d= iv> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);"><br> </span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">Regards,</span></div> <div class=3D"elementToProof"><span style=3D"font-family: Aptos, Aptos_Embe= ddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 1= 2pt; color: rgb(0, 0, 0);">Christopher Hawker</span></div> <div id=3D"appendonsend"></div> <div style=3D"font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, = Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <hr style=3D"display: inline-block; width: 98%;"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><span style=3D"font-family: Calibri, = sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"><b>From:</b> NANOG = <[email protected]> on behalf of Jay R. = Ashworth <[email protected]><br> <b>Sent:</b> Tuesday, February 13, 2024 5:19 PM<br> <b>To:</b> North American Operators' Group <[email protected]><br> <b>Subject:</b> The Reg does 240/4</span> <div> </div> </div> <div><span style=3D"font-size: 11pt;">I know we had a thread on this last m= onth, but I can't remember what it<br> was titled.<br> <br> ElReg has done a civilian-level backgrounder on the 240/4 issue, for anyone= <br> who wants to read and scoff at it. :-)<br> <br> <a href=3D"https://www.theregister.com/2024/02/09/240_4_ipv4_block_activism= /" id=3D"OWA90c20dbb-5e8f-7875-1393-2e384bf05835" class=3D"OWAAutoLink" dat= a-auth=3D"NotApplicable" data-loopstyle=3D"linkonly">https://www.theregiste= r.com/2024/02/09/240_4_ipv4_block_activism/</a><br> <br> Cheers,<br> -- jra<br> <br> --<br> Jay R. Ashworth = Baylink &= nbsp; &nbs= p; [email protected]<br> Designer &= nbsp; The Things I Think&nb= sp; = RFC 2100<br> Ashworth & Associates <a href=3D"ht= tp://www.bcp38.info" id=3D"OWAa9283bbf-1d91-7b87-c764-6743cb122ced" class= =3D"OWAAutoLink" data-auth=3D"NotApplicable" data-loopstyle=3D"linkonly"> http://www.bcp38.info</a> &n= bsp; 2000 Land Rover DII<br> St Petersburg FL USA BCP38: Ask For It By Nam= e! +1 727 647 1= 274</span></div> </body> </html> --_000_SYBP282MB05387ACE2E155E6779A0EDD1CC4F2SYBP282MB0538AUSP_--