This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] IPv4 waiting list policy
- Previous message (by thread): [address-policy-wg] IPv4 waiting list policy
- Next message (by thread): [address-policy-wg] IPv4 waiting list policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Mathias Westerlund
mathias.westerlund at wdmab.se
Fri Dec 10 10:17:52 CET 2021
Hello, I would just like to chime in on this aswell, not as much as a long standing member with lots of experience of being an LIR or even an RIPE member, but rather on the complete opposite side of the spectrum. We are an VERY small ISP/MSP that have been approached by an fairly (the largest) FTTH provider in the nordics to be bundled as ISP for home consumers and MSP/ISP for companies they install fiber for during the next year or two in central sweden. This means that for us we are now under massive pressure to acquire all the resources required to start delivering this in january/February from the new datacenters in two more locations and all the links as well as the IP ranges we intend to use for CG:nat for our consumer customers. We have an /24 from prior to us becoming an member but that is entirely allocated to our WISP service and our primary hosting datacenter. We started the process of becoming an member and LIR about a week prior to the meetings (Unbeknownst to us) at that point there was zero in line for the /24 allocations and we were feeling confident that "Any day now our application will go through nd we can get an /24 almost immediatly" that is almost a month ago now and in the 5 days from that until when we could actually request an allocation as we finally became an member the queue became 150-200 ish and has only gone up since with the "Longest waiting" application going up with one day every days, and as such the queue is standing still solid. This is worrying from us because even if we are planning to use IPv6 native on everything and all clients there is sadly a massive ammount of IPv4 still needed especially as an ISP. What this means for us is that we are now being forced into becoming one of the buyers for the ranges that was intended for usecases like us but have been grabbed by organizations only intending to sell them. Causing us to pay way more for these IPadresses than we should have to really. I will be quite frank about this and say that it feel very disheartening to essentially miss the 0 day queue allocations by 5 days. end up in a one month long quque that just grows with no more allocations and on top of that it is VERY obvious that these organisations uses the members list as a "To be customers" base because about 4 hours after we became members we got mails and phonecalls from about 5 different companies stating they want to sell us IP adresses. It just feels like this is not what RIPE was intended for but obviously is being used for. I apologize if i am sounding too salty or if my mail is not according to well established RIPE etiquette, and dont get me wrong. we are VERY happy about being a new member with a single LIR and getting our own IPv6 and insight into the future of the internet, just felt that i should give the point of view of exactly one of those "Small new one lir members" that many here reffer to and exactly how our experience with this issue has been.. Regards, Mathias W CEO / Infrastructure Architect - West Digital Management AB. On Fri, Dec 10, 2021 at 4:59 AM Florian Fuessl <flo at degnet.de> wrote: > Personally, I think a mixed approach may help to decrease the pressure on > the IPv4 waitlist. > Actions should aim to make it unattractive for address brokers to open new > LIR accounts to gain capital profit from IPv4 assets. > > It should not block reasonable legal actions on mergers, acquisitions, or > other changes in the business structure of LIRs. > > Therefore instead of locking IPv4 resources from the IPv4 waitlist as > non-transferable, it’s probably more effective to set up an inverse fee on > these types of changes in the LIR business structure. > > For example: > - leave the existing policy blocking these actions within the first 24 > months. > - after 24 months a one-time fee like ( 10 {years} - $years-of-membership > ) * $current-annual-LIR-service-fee has to be paid to execute mergers and > acquisitions including IPv4 resources. > > The gain of the policy change should be: > - not to affect long time LIRs and reasonable resource usage > - allow changes in the business structure of LIRs > > Having to pay a painful one-time service fee after the lock period makes > it a risky deal for address brokers to incorporate new LIR startups to gain > cheap IPv4 resources for later sale or mergers. > But it is not going to block reasonable changes in business structure. > > Kind regards > Florian Fuessl > > > Am 09.12.2021 um 08:56 schrieb Gert Doering <gert at space.net>: > > > > Signierter PGP-Teil > > Hi, > > > > On Thu, Dec 09, 2021 at 12:26:35AM +0000, Nick Hilliard wrote: > >> I sympathise with what you're trying to achieve here: you want to > design > >> a policy mechanism which prioritises new entrants who need IPv4 > >> resources so that legitimate new businesses can operate successfullt. > >> Problem is, none of the mechanisms that have been proposed so far on > >> apwg are going to work, or else they are likely to have unexpected and > >> potentially serious downstream consequences. > > > > So, if you were to decide, what would you do? > > > > Gert > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael > Emmer > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://mailman.ripe.net/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20211210/56fc65c7/attachment.html>
- Previous message (by thread): [address-policy-wg] IPv4 waiting list policy
- Next message (by thread): [address-policy-wg] IPv4 waiting list policy
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]