Thank you for this example Massimiliano !

It is very good example how bad the resources can be used, and how bad is
to have flat fee for all members ! That's why RIPE fee _MUST_ include per
resource component.

I am currious about technical aspects in the logic, Even if you go
with EUI-64 standart for your network infrastructure (nobody do this,
because the addresses unprediction) a /29 IPV6 will let you have 34 358
689 800 ( > 34 Bilions segments). With the maximum ttl value of 255
(limited by the one byte in the header, current around the internet is
used just 64), You can have 134 739 960 (> 134 millions) router
interfaces. With the modern switching asics, you will need and around
144 000 000 000 000 (> 144 trillions) ethernet switches where you can
connect up to 18446744073709551616 end hosts per segment. Let me also
remind that IPV6 protocol allow to use a single (just one) adress per a
system/ruter/host (not per interface as IPV4) implemented in almost all
vendors equipment and OS.

Yes in theory it is posible to need huge address space, but in theory
every one of us (LIRs) have to drawn all ipv6 + ipv4 + ASN from IANA (not
from RIPE only) to cover all very unlikely future needs.

-----

The problems RIPE NCC and we members have, is not the charging scheme is
fair or unfair, the root of the problem is _UNFAIR RESROURCES
DISTRIBUTION_ during the years. As everything in the real world internet
resources are also finite numbers. So how to spread finite resources to
group of members which by presumptions are equal (First and most
important RIPE obligation - threat all members equally) ? Logically -
equal. If we were 5 members maybe we can handshake each other and have an
agreement (not sure ether when we talk about concurent companies /
personals), but we are 21k that's why we need clear, transparent and
strong rules equal to all. We currently have a strong discrimination based
on very vague foundations and rules.

I will be very happy somebody from RIPE to explain us, why one member can
hold /8 just for fun (or testing or whatever), in the same time other
member to have single /24 (or to be in a waiting queues) extreamly
dificult to operate its bussiness because lack of resources and both of
them to be forced to pay same fee. Which rule in the RIPE founding
agreement exactly says this is fair and equal ? Also how many from the
RIPE NCC staff and you LIRs, with hand on heart will tell the current
situation is moral, normal and fair to all ?

In all cases after the posible delegated resources to RIPE have limits we
also need limits for the resource each of us can hold and operate with.
thing more fair can be than to take all resources in each category
(IPV4/IPV6/ASN) which are delegated to RIPENCC and divide by the LIR
members number.


Solution one:
Redistribute resources equaly to all. Not imposible as I already wrote,
but will that lead to tremors in the work of operators - very likely. But
what is that is equal fees, equal rights, equal resources.

Solution two:
Start to "penalise" the the LIRs which holds and operate resources over
the fair share limits. That will not make disruption of the internet work
in the region. And will give time to those who want to optimise the
resource usage to do it and save expenses. How to do it ? - With money
ofcourse. To prevent adding too much initial stress to all, we have to
start with small steps and calibrate the "penalisation" fee with time.

As I wrote in my previous mail the current fair shair resources for each
LIR member based on what I checked (by IANA documents and 21500 LIRs) are:

1 x /18 IPV4 block
1 x /28 IPV6 block
16 x ASN

Everything above these numbers should be "penalise" with a small fee per
each resource over the limit. Ofcourse these limits must be shifted if
we become 40k members or down to 10k, but it is an easy part. Also
"penalty" fee by 10 euro per year for /24, /32, ASN looks prety resonable
in the light of current free market prices - 15k "buy" / 100 euro month
rent.

It is not a category based charging scheme !
It is fair share charging scheme !
Can be looked at like extension of the scheme C, but guarantee much more
RIPE NCC sustainable future and covers all LIR resources (not only PI).
Current offered option C is inanity, because one LIR can hold /8 PA and
none PI space, the other can hold single /24 PA and 10 x /24 PI, and will
pay much more than the first one with /8 PA (fair ?) !


Another important theme is RIPE-639. 10 Years after the adoption we still
have nearly 34% undiscovered resources. How much more time it needs ? If
for 10 years you cant find legacy holders what will be the chance to do
it in the next 10 or 100 years ? We need a straight deadline to point
2.6. I think RIPE NCC can safely suspend (not delete) all records for
these 34% resources. It is good to put dummy records to point to call or
email to RIPE support staff, and these resource to be gobaly announce. If
nobody call in few (3) mounths, can be consider free and can be drawn into
the pool.



Ivaylo Josifov
VarnaIX / Varteh LTD
+359 52 969393
Varna, Bulgaria


On Fri, 26 Apr 2024, Massimiliano Stucchi wrote:

>
> Hi,
>
> On 26.04.2024 16:40, Thibaud Perret wrote:
>
>> I have a question for Massimiliano, if he sees it:
>>   Do you really need that many IPv6 addresses? Couldn't you just go with a
>> single
>> /40 allocation instead? That would still make a couple of /48 to be
>> announced
>> separately for you to keep your "lab allocation". If the answer is "yes" to
>> that
>> question, you could then pay well less in most if not all other RIR
>> regions.
>
> I could do with a much smaller allocation.  At present, I'm announcing both
> /29s, with the first one being where my infrastructure is (and an address I'm
> writing this e-mail from), and the second /29 has been used for some research
> such as the one you can find here
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flabs.ripe.net%2Fauthor%2Fstucchimax%2Fa-bgp-side-effect-of-rpki%2F&data=05%7C02%7C%7C0b84b59374a24b82c60308dc661e588c%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638497527736209710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=y2T5QV8Ea7AuXD4WBPSVxPxiuOcA80pYk7PGy8LHnyQ%3D&reserved=0).
>
> The point of the article was to compare what a "normal" LIR would pay in the
> different RIRs.  If I were to compare having a /48 (which would be PI at that
> point) I would be comparing two different things.
> Additionally, I wanted to showcase how some decision could be hindering
> Internet development, such as the one from LACNIC to charge so much for IPv6
> compared to all the other RIRs, and the similar situation at APNIC, although
> to a lesser extent.
>
> To wrap this, could I do with a smaller allocation? Definitely. But I
> received a /29 as part of my membership and I can make some use of it. I
> could also live without a second /29, but that does not increase my
> membership fees.  I would return it if the charging scheme were to be like
> APNIC or LACNIC.
>
> Ciao!
>
> --
> Massimiliano Stucchi
> MS16801-RIPE
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstucchi.ch%2F&data=05%7C02%7C%7C0b84b59374a24b82c60308dc661e588c%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638497527736218822%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=CCE0El%2F5B41Uiky2BkscGB%2Fb%2FnkIWS2tKh4KGwPNA%2F4%3D&reserved=0
>

_______________________________________________
members-discuss mailing list
members-discuss@ripe.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Flistinfo%2Fmembers-discuss&data=05%7C02%7C%7C0b84b59374a24b82c60308dc661e588c%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638497527736224712%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=AKpL%2FBU%2BGivvG9mSvj2oFyeYeLXVit3cGEBi0iHep9Y%3D&reserved=0
Unsubscribe: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ripe.net%2Fmailman%2Foptions%2Fmembers-discuss%2Fkajtzu%2540basen.net&data=05%7C02%7C%7C0b84b59374a24b82c60308dc661e588c%7Cd0b71c570f9b4acc923b81d0b26b55b3%7C0%7C0%7C638497527736228202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C4000%7C%7C%7C&sdata=wGy%2BZKcmJxuRIwj9%2BTXb5a6zDlImgJ%2BgmCg51B4zlw8%3D&reserved=0