<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Yes, by all means. Let's stop all research and development
      globally, because we already know every possible further
      development will fail because of previous failures, therefore any
      attempts for further development on anything would be futile and
      fruitless.</p>
    <p>-- That logic does not compute, sorry.<br>
    </p>
    <p>Do you know how many attempts Edison had to do to make the first
      light bulb? Maybe he should've just stopped after a couple of
      attempts and deem it impossible?</p>
    <p>Just because prior proposals/methods/ideas didn't work, doesn't
      mean a new one wouldn't or that all avenues have been explored.<br>
      Like i stated earlier, all the prior proposals i have seen are
      convoluted and complicated, mixing up things that don't belong
      there.<br>
    </p>
    <p><br>
    </p>
    <p>So what's the complete unworkable thing on this?<br>
      It requires zero network upgrades, only end points need to
      understand this. Therefore, adept coder makes a patch, it gets
      included in Linux kernel after a while of testing, and just couple
      years down the line you have what 90-95% of servers supporting it
      already?</p>
    <p>Please by all means, show how this would not work.<br>
      I am curious as to why?<br>
    </p>
    <p><br>
    </p>
    <p>Br,<br>
       Aleksi<br>
       Magna Capax Finland Oy<br>
      <br>
    </p>
    <div class="moz-cite-prefix">On 01/04/2024 16.38, Q Misell wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAMEWqGv_yz38c9UoVOtfFU_g-Qt1HTzZhNW2MJ-1AD0bv8Hymg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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/LMqmSZRX"
                  target="_blank" moz-do-not-send="true">12417574</a>,
                LEI 875500FXNCJPAPF3PD10. ICO register №: <a
                  href="https://e.as207960.net/w4bdyj/AmZwGXyq"
                  target="_blank" moz-do-not-send="true">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"
              moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
              class="moz-txt-link-freetext">members-discuss@ripe.net</a><br>
            > <a href="https://e.as207960.net/w4bdyj/JqounabO"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://mailman.ripe.net/</a><br>
            > Unsubscribe: <br>
            > <a href="https://e.as207960.net/w4bdyj/bXMhzevz"
              rel="noreferrer" target="_blank" moz-do-not-send="true">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"
              moz-do-not-send="true" class="moz-txt-link-freetext">members-discuss@ripe.net</a><br>
            <a href="https://e.as207960.net/w4bdyj/Z54J0XCc"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://mailman.ripe.net/</a><br>
            Unsubscribe: <a
              href="https://e.as207960.net/w4bdyj/koxbybwf"
              rel="noreferrer" target="_blank" moz-do-not-send="true">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/S4n6LDSx0r2Y" alt=""
          moz-do-not-send="true"></p>
    </blockquote>
  </body>
</html>