[members-discuss] RIPE NCC Charging Scheme 2025 Open House: Recording and Slides Available

Hi,

  For Profit or Non-Profit, the type of organization shouldn’t influence 
RIPE fees.
If a non-profit cannot get that minimal amount of revenue in, it 
probably is not worth operating and does not bring sufficient amount of 
value to its members to be able to even raise enough for increased RIPE 
costs.

  We are not operating in a vacuum; unless fee increases are matched by 
ARIN, APNIC, and others, any increase would further disadvantage 
European operators. That would make us Europeans even more the memeable 
"Europoors" and at even further disadvantage in the market place 
(taxation and bureaucracy being heavy, VAT etc. are already a huge 
disadvantage for those of us whose target audience is global. European 
private customers significantly avoid us because of VAT; We have to sell 
at lower prices than competitor by roughly the amount of average VAT.)

  Perhaps upkeep of IPs should cost more, that would eventually start 
vacating addresses due to upkeep cost, which would lower the acquire costs.
However, RIPE does not operate in a vacuum. If RIPE is the first to 
increase fees and others don’t follow...

  Capitalism is by far the best known way to man to distribute resources 
efficiently.
There's nothing else which comes even close for resource distribution 
efficiency.


----


  As a small business owner we have not implemented IPv6 at all, nor 
have plans for such. It's too costly for little to no benefit.
All our customers need IPv4 regardless, and no-IPv4 address drops the 
marketable price so so very low it's not worth the effort to do.
 From our customer base, maybe 1% or less of traffic would go over IPv6, 
and in ~every case, IPv4 is also available. Even the most prolific IPv6 
advocate customer we've had, had to ultimately admit it would be at most 
4-4.5% which would go over IPv6 -- and on his case, i'm certain he was 
exaggerating by multitudes.

  Many of our business decisions are driven by the cost of acquiring 
IPv4 addresses, and admittedly we've been hoarding a little bit in order 
to do a project, and expect to exhaust our available addresses very soon 
after launch.

  As costly as IPv4 addresses are, IPv6 addresses cost orders of 
magnitude more, even before accounting for the (lack of) usefulness 
factor. This despite over 2 decades since first time using IPv6 (Since 
the early implementations of IPv6, using HE.NET tunnel service). IPv6 
would actually decrease the performance and value for our end users, 
only perception of value would increase.

  Costs are not in hardware, that's cheapest and easiest portion 
actually -- even if you have to buy a brand new router. The true cost is 
in the administrative side, all of the extra steps and processes needed 
to maintain IPv6 addressing, extra security precautions (some people 
demand a /56 for themselves, and then uses a new IPv6 address for each 
new application start, exhausting switch/router caches, essentially 
DOS'ng the network). It all is a continuous drag and extra work. What's 
most expensive is human effort, and if you now take something which used 
to take 3 seconds each time, and expand it to be 30 seconds, or even 10 
seconds, multiply it by X times per day, for Y years -- it all becomes 
really really rather expensive. You might say "but you can automate 
this" -- Someone has to create that automation and rules first still. 
All of which exists, is abundant, and well tested for IPv4 but not for IPv6.

  Personally i do not believe IPv6 will become mainstream ever, for the 
basic fact that not everyone will ever support it, therefore IPv4 is 
always required.
You'd be surprised from what kind of places i hear customers/end users 
being instructed to actually remove IPv6 to have their network operating 
more smoothly. Places you'd never expect, and would actually expect to 
be advocates for IPv6.


----


  Technical solution; There's been some proposals for "IPv4e", extending 
IPv4 addressing by a few bits, as an addon. All of those proposals have 
also mixed features and layers, tried to put stuff not belonging in this 
layer to it. Just like IPv6. It's easy to think complicated == good, but 
reality is, the simplest solution is almost always the right answer.

  I don't know the low level well enough to do a proof of concept, but 
have postulated for more than a decade now that it could be possible to 
add "extension", and keep routing the same, only software updates on the 
extension area; gateways, client and server. 10.10.10.10 could have 2 
additional segments, extra 16 bits used per packet + how many bits to 
identify in header this is extended address.

A packet arrives to 10.10.10.10 and have extension segments of .5.5 set 
in the packet headers, therefore target is 10.10.10.10.5.5, and only the 
10.10.10.10+10.10.10.10.5 gateway/routers, and 10.10.10.10.5.5 server 
along with the client needs to understand the extension. Reaching for 
10.10.10.10 would not have those extra bits set.
In the extended network area devices have to understand this tho, but 
only in the extended area, otherwise ARP tables etc. would not work.

  Since it's just software for the most part, and for the most part only 
client & server, this would get distributed over time like "magic", 
automatically. Old routers with old software, old ASICs would continue 
to work, it's only what comes after them needing to understand what 
those bits in the header mean.
In other words; For the first steps of mass adoption, only OSs need to 
be updated. Would get adopted more than IPv6 in manner of a OS 
lifecycle, initially people could utilize those more like ports, assign 
an IP per application as an example, or for IoT.
A decade later, this would automatically have probably 95+% adoption 
rate on the OS side, which is more than sufficient for switching chip 
manufacturers to add the support for that 16-24bits required.

  Even the network admins don't need to know this is running at all, if 
they don't want to. End users can still benefit from it.
Even better, this probably could be made dynamic, add extension 8 bit 
segments on as needed basis to a certain maximum. so a /32 could have 
added /24 or /16 or /8 of added IPs, however many bits we'd decide as 
the maximum depth. 16? 24? another 32? maybe even 48 or 64? -- and 
everyone currently working in networking (or even somewhat close to) 
would understand this methodology, it's just added segments of 
addressing. KISS - Keep It Simple, St***d!

  For Legacy stuff, NAT works fine, but it could be extended further to 
have just translation of extended address to a internal IP and 
vice-versa. Computationally, would cost very little, less than typical NAT.

  Ultimately, everyone would understand this, and would probably still 
fit into the working memory of most normal human beings :) This would 
not be a paradigm shift in thinking, and could be metaphorically be 
described as "special NAT". Just an extension, an extended range.

  And all this "IPv4e" would do is just extended addressing, nothing 
else, nothing more, nothing less. Only that, and nothing else. No 
confusion, no ifs, no buts, just Keep It Simple.

  To be fair, this might be Dunning-Kruger effect, i haven't worked at 
that low level really ever (a little bit maybe early 00s crafting 
packets manually) and there are far more knowleadgable people who could 
immediately say do we have means to add those packet headers. We should, 
since we got things like LACP, VLANs etc etc. all of which takes packet 
header space.

Despite this, I have yet to speak with a network engineer who has 
explained why this wouldn't work. Some have even suggested that I should 
write an RFC on this topic.

However, i digressed here a little bit off topic ...


Best Regards,
  Aleksi
  Magna Capax Finland Oy

PS. I typically only lurk on this mailing list and read only a few 
random responses, if you want to discuss IPv4e further feel free to 
contact me directly. With your feedback, perhaps an RFC shall finally be 
written, a RFC more than a decade in the making.


On 01/04/2024 12.35, Mihail Fedorov wrote:
> Hi Hank!
>
> No one is assuming any disrespect to IUCC and it’s part in building 
> internet here. But I just bothered checking (sorry, did it just for an 
> example) - IUCC owns two /16’s, one /18 and lots of /20-/22s. Can you 
> check for us how many of them are actually assigned to some interfaces?
>
> Typically it will be below 10%. If I’m right - that means that IUCC 
> alone stops at least 576 small non-profit or startup networks from 
> being legitimate part of routing table.
>
> If I’m wrong - please forgive me and just give me /24 to subrent :-)
>
> And yes, I assume that any company who administer 65000 interfaces 
> (65000 computers or routers) should feel affordable paying ~6500 - 
> ~65000 USD - effectively solving all possible RIPE financing problems. 
> Except very rare cases of large non-profit networks.
>
> P.S.: Each and every small network I see on IX has already appreciated 
> and implemented IPv6 support. But realistically they still need some 
> v4. And only large v4 space holders sometimes do not bother 
> implementing IPv6 at all.
>
>> On 1 Apr 2024, at 11:49, Hank Nussbacher <hank at interall.co.il> wrote:
>>
>> On 29/03/2024 14:49, Gert Doering wrote:
>>
>> IUCC was the first paying member to RIPE NCC in 1995 (since we 
>> realized the importance of supporting such a fledgling organization) 
>> and we have paid for our resources for the past 29 years.
>>
>> See attached (page 3 of 4 pages - if anyone wants to see the full 4 
>> page document - drop me an email off-list).
>>
>> Regards,
>> Hank
>>>
>>>> Hi,
>>>>
>>>> On Thu, Mar 28, 2024 at 07:04:30PM +0100, Andrea Borghi wrote:
>>>>> My humble proposal is to class basing on how many additional 
>>>>> resources a
>>>>> company have beyond the basics that was valid at the time of 
>>>>> joining Ripe.
>>>>
>>>> ... and possibly how old these resources are... we got our blocks in
>>>> 1995/1996, and they are considered "large" by today's standards.  Back
>>>> then, it was what you got as a fast-growing small ISP...
>>>>
>>>> So if we really go for something based on allocation size, adding a
>>>> yearly depreciation factor in would make this "more fair" (... we've
>>>> been paying our share for the last 29(!) years already).
>>>>
>>>> Gert Doering
>>>> -- NetMaster
>>>>
>>>>
>>>> _______________________________________________
>>>> members-discuss mailing list
>>>> members-discuss at ripe.net
>>>> https://mailman.ripe.net/
>>>> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/hank%40interall.co.il
>>
>> <ripe.jpg>_______________________________________________
>> members-discuss mailing list
>> members-discuss at ripe.net
>> https://mailman.ripe.net/
>> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/mihail%40fedorov.net
>
>
> _______________________________________________
> members-discuss mailing list
> members-discuss at ripe.net
> https://mailman.ripe.net/
> Unsubscribe:https://lists.ripe.net/mailman/options/members-discuss/aleksi%40magnacapax.fi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20240401/d420716d/attachment-0001.html>