<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature">>  "IPv4e" -- You probably missed the point about it not needing hardware<span class="gmail-Apple-converted-space"> </span>updates initially at all?</div><div dir="ltr" class="gmail_signature"><br></div><div dir="ltr" class="gmail_signature">Can we please stop discussing upgrades to IPv4. Every single suggestion that anyone has presented in recent years has been proven entirely unworkable.</div><div dir="ltr" class="gmail_signature">It's not worth even discussing them at this point.<br>

<hr style="height:1px;background-color:rgb(203,213,224);margin-top:1rem;margin-bottom:1rem;border:0px">

<p style="font-size:12px;color:rgb(108,117,125)">
  Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated.
  AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № <a href='https://e.as207960.net/w4bdyj/UUf4xoYQ' target="_blank">12417574</a>, LEI 875500FXNCJPAPF3PD10.
  ICO register №: <a href='https://e.as207960.net/w4bdyj/qThuTXEi' target="_blank">ZA782876</a>.
  UK VAT №: GB378323867.
  EU VAT №: EU372013983.
  Turkish VAT №: 0861333524.
  South Korean VAT №: 522-80-03080. 
  AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532.
  Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.
</p></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 Apr 2024 at 13:54, Aleksi <<a href="mailto:aleksi@magnacapax.fi">aleksi@magnacapax.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
  "IPv4e" -- You probably missed the point about it not needing hardware <br>
updates initially at all?<br>
Only software. Routing etc. would all remain identical, those extra bits <br>
would be in the packet header and only end points need to understand <br>
those headers.<br>
<br>
52% is not sufficient IPv6 connectivity, even 100% would not be -- It <br>
needs to match or exceed IPv4 performance. ie. routing has to be better.<br>
Unfortunately, due to design, i don't think that's feasible ever either <br>
because the routing tables will grow exponentially larger than IPv4.<br>
Right now, IPv6 route is often weaker than IPv4 to my experience.<br>
<br>
IPv6 OpEx is much higher than IPv4, to our experience as well. It's not <br>
even a competition.<br>
<br>
Br,<br>
  Aleksi<br>
  Magna Capax Finland Oy<br>
<br>
<br>
On 01/04/2024 15.37, ivaylo wrote:<br>
><br>
> The subject of this discussion go a lot ofside. I dont know why you <br>
> bloat the theme (maybe it is intensionly ?) leading it to IPV4 <br>
> holding. Our main focus _SHOULD_ be RIPE budget and financing + <br>
> sustainabla operation in the next year and in the future at all. This <br>
> of course is related with the members fee.<br>
><br>
> I done a little research and calculations, to tune my initial <br>
> propousal so: By IANA public documents current delegated resources to <br>
> RIPE are:<br>
><br>
> 86016     IPV4 /19 blocks<br>
> 66624     IPV6 /27 blocks<br>
> 42882     ASN<br>
><br>
> If we have a hard coded limits for each LIR, equal steps up, and <br>
> member fee of 750 EURO per year, each LIR can hold up to:<br>
><br>
> 1 x /19 IPV4 BLOCK (sumary = 32 x /24 networks)<br>
> 1 x /27 IPV6 BLOCK (sumary = 32 x /32 networks)<br>
> 16 ASN numbers<br>
><br>
> After pass one of the above parameters even with one /24 IPV4, /32 <br>
> IPV6, or ASN, +750 euro (1500 euro RIPE fee) up to the next <br>
> proporcional limit:<br>
><br>
> 2 x /19 IPV4 BLOCK (sumary = 64 x /24 networks)<br>
> 2 x /27 IPV6 BLOCK (sumary = 64 x /32 networks)<br>
> 32 ASN numbers<br>
><br>
> and so on...<br>
><br>
> This will generate 64 512 000 euros annual budget for RIPE which is <br>
> absolutely enough for normal operations in each of the next 10 years, <br>
> without need to increse members fee each year.<br>
><br>
> If somebody is afraid, that other RIRs will not keep going with RIPE <br>
> fees, and there will be posibly leave of the big resource holders, <br>
> keep in mind that all small members from the other RIRs will move to <br>
> RIPE. Also good luck moving to ARIN db mess, the risk to lost route of <br>
> your prefixes is nearly 90%.<br>
><br>
> ----------<br>
> Off topic: About IPV4/IPV6 resources, it is imposible to create kind <br>
> of ipv4 adress space extension. Many hardware do lookup over the ip <br>
> header, it is not only software related. Even somebody develope a <br>
> public standart about that, will take decades before all replacing <br>
> equipment all over the world and another decades all to be workable. <br>
> We have working IPV6, right now more than 52% has IPV6 connectivity. <br>
> Biggest EU access operator already<br>
> give dual stack IPV4/IPV6 even to their end users, and activlly deploy <br>
> IPV6 stack into their networks. It is much more cheaper in long <br>
> perspective than to buy/rent IPV4 (NAT/proxy your clients/services <br>
> over IPV4 and give them IPV6 real addresses). After 2-3 years the core <br>
> of the Internet will be over IPV6, yes we will need to support IPV4 <br>
> for the next 10-15 years to provide backward connectivity, but it is a <br>
> dead end. All who thinks they will do a big profit from IPV4 adresses <br>
> they hold, do seriously mistake in their logic, but anyway it is their <br>
> problem. Those who dont implement IPV6 because "yay it is so scary and <br>
> not working" in one moment will have to do this fast without <br>
> experience, because will have seroius troubles with IPV4 connectivity.<br>
><br>
><br>
><br>
><br>
> Ivaylo Josifov<br>
> VarnaIX / Varteh LTD<br>
> +359 52 969393<br>
> Varna, Bulgaria<br>
><br>
> _______________________________________________<br>
> members-discuss mailing list<br>
> <a href="mailto:members-discuss@ripe.net" target="_blank">members-discuss@ripe.net</a><br>
> <a href='https://e.as207960.net/w4bdyj/nwsafSYy' rel="noreferrer" target="_blank">https://mailman.ripe.net/</a><br>
> Unsubscribe: <br>
> <a href='https://e.as207960.net/w4bdyj/lKIRGjqw' rel="noreferrer" target="_blank">https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi</a><br>
<br>
_______________________________________________<br>
members-discuss mailing list<br>
<a href="mailto:members-discuss@ripe.net" target="_blank">members-discuss@ripe.net</a><br>
<a href='https://e.as207960.net/w4bdyj/QfQSapxf' rel="noreferrer" target="_blank">https://mailman.ripe.net/</a><br>
Unsubscribe: <a href='https://e.as207960.net/w4bdyj/tkTS5opB' rel="noreferrer" target="_blank">https://lists.ripe.net/mailman/options/members-discuss/q%40as207960.net</a><br>
</blockquote></div></div>
<p class='ampimg' style='display:none;visibility:none;margin:0;padding:0;line-height:0;'><img src='https://e.as207960.net/img/w4bdyj/cgyjdYFXVuNG' alt=''></p>