From mschmidt at ripe.net Tue Dec 7 10:22:59 2021 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 7 Dec 2021 10:22:59 +0100 Subject: [address-policy-wg] IPv4 waiting list policy Message-ID: Dear colleagues, In the Address Policy Working Group sessions at RIPE 83, I shared our observations regarding the IPv4 waiting list policy. [1] The intent of this policy was to provide newcomers with a minimal amount of IPv4 space for as long as possible. However, about half of these allocations went to members that received several /24 allocations via multiple LIR accounts. As there was interest in reviewing the policy at the RIPE Meeting, I would like to provide more detail on the provision of IPv4 allocations over the last two years and the current situation with the waiting list. In the last 24 months, we provided 4,178 LIRs with a /24 allocation: -??? 2,019 allocations (48%) went to members with a single LIR account -??? 452 allocations (11%) went to members with 2-4 LIR accounts -??? 298 allocations (7%) went to members with 5-9 LIR accounts and -??? 1,409 allocations (34%) went to members with 10 or more LIR accounts (up to 33 /24 allocations to a single member) This trend towards allocations to multiple LIR accounts has accelerated in the past six months. Between June and November 2021, only 24% of allocations went to members with a single LIR account, while 54% went to members with 10 or more accounts. We see the same trend with the current waiting list. At the time of writing, we can see 327 requests for a /24 allocation: -??? 83 (25%) are from members with a single LIR account -??? 42 (13%) are from members with 2-4 LIRs accounts -??? 45 (14%) are from members with 5-9 LIR accounts -??? 157 (48%) are from members with 10 or more LIR accounts Consequently, there is a significantly longer wait time for members with a single LIR account. Looking at the current market prices for IPv4 in comparison to our membership fees, even a wait time of several months is acceptable for organisations that plan to transfer their allocation after the end of the holding period. Conversely, the long wait time will create uncertainty for real newcomers, especially if they can?t rely on IPv6-only networks. I hope the WG finds this information useful for further discussion. If there is consensus to change the current situation, there are several approaches available ? including a review of the waiting list policy and changing ?per LIR? to something else. Other approaches, such as a different charging scheme or changing the concept of multiple LIRs would need to be approved by the RIPE NCC membership. Kind regards, Marco Schmidt Assistant Manager Registry Services RIPE NCC [1] https://ripe83.ripe.net/archives/video/642/ From thomas at brenac.eu Tue Dec 7 10:54:46 2021 From: thomas at brenac.eu (Thomas Brenac) Date: Tue, 7 Dec 2021 10:54:46 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Hello Indeed this surge in the waiting list is a show stopper for new comers that really rely on this allocation to initiate their business and have a timed business plan. I would suggest that allocation priority is given to new single LIR (upper priority) down to lower priority for those with more than 10 LIR. My 2 cents Thomas BRENAC http://www.brenac.eu +33686263575 CEO IPv4 Broker registered with RIPE NCC, ARIN, APNIC and LACNIC Member of AFRINIC Marco Schmidt 7 d?c. 2021 ? 10:23:35 wrote: > > Dear colleagues, In the Address Policy Working Group sessions at RIPE 83, I shared our observations regarding the IPv4 waiting list policy. [1] The intent of this policy was to provide newcomers with a minimal amount of IPv4 space for as long as possible. However, about half of these allocations went to members that received several /24 allocations via multiple LIR accounts. As there was interest in reviewing the policy at the RIPE Meeting, I would like to provide more detail on the provision of IPv4 allocations over the last two years and the current situation with the waiting list. In the last 24 months, we provided 4,178 LIRs with a /24 allocation: - 2,019 allocations (48%) went to members with a single LIR account - 452 allocations (11%) went to members with 2-4 LIR accounts - 298 allocations (7%) went to members with 5-9 LIR accounts and - 1,409 allocations (34%) went to members with 10 or more LIR accounts (up to 33 /24 allocations to a single member) This trend towards allocations to multiple LIR accounts has accelerated in the past six months. Between June and November 2021, only 24% of allocations went to members with a single LIR account, while 54% went to members with 10 or more accounts. We see the same trend with the current waiting list. At the time of writing, we can see 327 requests for a /24 allocation: - 83 (25%) are from members with a single LIR account - 42 (13%) are from members with 2-4 LIRs accounts - 45 (14%) are from members with 5-9 LIR accounts - 157 (48%) are from members with 10 or more LIR accounts Consequently, there is a significantly longer wait time for members with a single LIR account. Looking at the current market prices for IPv4 in comparison to our membership fees, even a wait time of several months is acceptable for organisations that plan to transfer their allocation after the end of the holding period. Conversely, the long wait time will create uncertainty for real newcomers, especially if they can?t rely on IPv6-only networks. I hope the WG finds this information useful for further discussion. If there is consensus to change the current situation, there are several approaches available ? including a review of the waiting list policy and changing ?per LIR? to something else. Other approaches, such as a different charging scheme or changing the concept of multiple LIRs would need to be approved by the RIPE NCC membership. Kind regards, Marco Schmidt Assistant Manager Registry Services RIPE NCC [1] https://ripe83.ripe.net/archives/video/642/ -- 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: From erik at bais.name Tue Dec 7 15:29:15 2021 From: erik at bais.name (Erik Bais) Date: Tue, 7 Dec 2021 14:29:15 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Hi Marco, Thank you for the detailed information of the dispersion about the current and past of the waitinglist. To the WG: The current workings of the IPv4 Waitinglist is specified in the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region https://www.ripe.net/publications/docs/ripe-733#5 Currently there is a First Come First Serve procedure for the waitinglist .. and there are no limitation to allocating v4 space to members that have been already allocated v4 space since the waitinglist started. I think that I speak for the WG, that the intent for the final /8 policy and the waitinglist policy, is to provide IPv4 (at least a small bit) to newcomers .. meaning that how it currently works and how it was intended .. that this might not align with what the WG initially wanted. If a change would be desired by the WG, it should go through the PDP, meaning that a policy change would be required. As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution. Regards, Erik Bais On behalf of the AP-WG Co-Chair collective. ?On 07/12/2021, 10:23, "address-policy-wg on behalf of Marco Schmidt" wrote: Dear colleagues, In the Address Policy Working Group sessions at RIPE 83, I shared our observations regarding the IPv4 waiting list policy. [1] The intent of this policy was to provide newcomers with a minimal amount of IPv4 space for as long as possible. However, about half of these allocations went to members that received several /24 allocations via multiple LIR accounts. As there was interest in reviewing the policy at the RIPE Meeting, I would like to provide more detail on the provision of IPv4 allocations over the last two years and the current situation with the waiting list. In the last 24 months, we provided 4,178 LIRs with a /24 allocation: - 2,019 allocations (48%) went to members with a single LIR account - 452 allocations (11%) went to members with 2-4 LIR accounts - 298 allocations (7%) went to members with 5-9 LIR accounts and - 1,409 allocations (34%) went to members with 10 or more LIR accounts (up to 33 /24 allocations to a single member) This trend towards allocations to multiple LIR accounts has accelerated in the past six months. Between June and November 2021, only 24% of allocations went to members with a single LIR account, while 54% went to members with 10 or more accounts. We see the same trend with the current waiting list. At the time of writing, we can see 327 requests for a /24 allocation: - 83 (25%) are from members with a single LIR account - 42 (13%) are from members with 2-4 LIRs accounts - 45 (14%) are from members with 5-9 LIR accounts - 157 (48%) are from members with 10 or more LIR accounts Consequently, there is a significantly longer wait time for members with a single LIR account. Looking at the current market prices for IPv4 in comparison to our membership fees, even a wait time of several months is acceptable for organisations that plan to transfer their allocation after the end of the holding period. Conversely, the long wait time will create uncertainty for real newcomers, especially if they can?t rely on IPv6-only networks. I hope the WG finds this information useful for further discussion. If there is consensus to change the current situation, there are several approaches available ? including a review of the waiting list policy and changing ?per LIR? to something else. Other approaches, such as a different charging scheme or changing the concept of multiple LIRs would need to be approved by the RIPE NCC membership. Kind regards, Marco Schmidt Assistant Manager Registry Services RIPE NCC [1] https://ripe83.ripe.net/archives/video/642/ -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From gert at space.net Tue Dec 7 15:56:14 2021 From: gert at space.net (Gert Doering) Date: Tue, 7 Dec 2021 15:56:14 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: Hi, On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote: > As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution. As a member of the WG, I do share the sentiment that the intent of the "IPv4 runout" policies have been "ensure that late comers to the game can have a bit of IPv4 space, to number their IPv6 translators", and not "grab some space for free, and sell it for more money elsewhere". I do not think this can be fixed on the AGM level ("one legal entity can only have one LIR account") - we've been there, in the rush to /22s, and all it does it "make people hide behind shell companies", so in the end, the address space goes out anyway, but registry quality suffers. Trying to make the NCC require even more paperwork isn't going to stop those that want to game the system, but will impact everyone else by making the NCC more annoying to deal with. My suggestion would be along the lines what was proposed on the APWG meeting already - earmark these /24s as non-transferrable, ever. Consequences: - there is no more financial incentive to "get one cheap, sell it expensive" - if you need space to run your business, this is exactly what it is there for - you can still sell your business (with the /24), you just need to keep the LIR account. But that's as with other business assets. - if you want to merge multiple LIR accounts, all having their own /24 - then you need to keep around these accounts, or return some of the /24s. - corrolary: if you use these /24s to number your IPv6 translators, then renumbering this translator into "your other /24" is actually not very hard. - corrolary2: If you use the /24s to directly number your customers, you missed the boat already (wearing my RIPE unicorn t-shirt today). Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jim at rfc1035.com Tue Dec 7 16:01:49 2021 From: jim at rfc1035.com (Jim Reid) Date: Tue, 7 Dec 2021 15:01:49 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> > On 7 Dec 2021, at 14:56, Gert Doering wrote: > > My suggestion would be along the lines what was proposed on the APWG > meeting already - earmark these /24s as non-transferrable, ever. +1 WFM -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 528 bytes Desc: Message signed with OpenPGP URL: From sander at steffann.nl Tue Dec 7 16:41:02 2021 From: sander at steffann.nl (Sander Steffann) Date: Tue, 7 Dec 2021 16:41:02 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> Message-ID: <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> Hi, >> On 7 Dec 2021, at 14:56, Gert Doering wrote: >> >> My suggestion would be along the lines what was proposed on the APWG >> meeting already - earmark these /24s as non-transferrable, ever. > > +1 WFM +1 from me as well. This would have very little (if any) impact on the newcomers for whom this policy was created. Transfers that have already happened should not be affected of course, but we can make a policy that stops new transfers being made in the future. I would prefer to disallow any new transfers, independent of when the assignment was made, to avoid a rush on the NCC for new memberships. Cheers, Sander From ripedenis at gmail.com Tue Dec 7 18:25:21 2021 From: ripedenis at gmail.com (denis walker) Date: Tue, 7 Dec 2021 18:25:21 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> Message-ID: Hi guys Many years ago I questioned why we ever invented a market for address space 'that no one owns' when we had a perfectly good system of allocating address space based on need and when no longer needed was returned to the RIR to be re-allocated...for free. I was told 'don't be silly, people will still sell the address space but not record the transfers in the RIPE Database'. So the quality of the registry diminishes. What is going to stop people selling these 'never to be transferred' allocations and not recording the transfer in the RIPE Database? I am sure some back door dealings can be arranged to keep the LIRs active that have the allocations registered and obfuscate the fee payments to confuse the RIPE NCC. Have companies developed some sense of morality in recent years? cheers denis co-chair DB-WG On Tue, 7 Dec 2021 at 16:41, Sander Steffann wrote: > > Hi, > > >> On 7 Dec 2021, at 14:56, Gert Doering wrote: > >> > >> My suggestion would be along the lines what was proposed on the APWG > >> meeting already - earmark these /24s as non-transferrable, ever. > > > > +1 WFM > > +1 from me as well. This would have very little (if any) impact on the newcomers for whom this policy was created. > > Transfers that have already happened should not be affected of course, but we can make a policy that stops new transfers being made in the future. I would prefer to disallow any new transfers, independent of when the assignment was made, to avoid a rush on the NCC for new memberships. > > Cheers, > Sander > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From gert at space.net Tue Dec 7 18:26:39 2021 From: gert at space.net (Gert Doering) Date: Tue, 7 Dec 2021 18:26:39 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> Message-ID: Hi, On Tue, Dec 07, 2021 at 04:41:02PM +0100, Sander Steffann wrote: > >> My suggestion would be along the lines what was proposed on the APWG > >> meeting already - earmark these /24s as non-transferrable, ever. [..] > Transfers that have already happened should not be affected of > course, but we can make a policy that stops new transfers being > made in the future. I would prefer to disallow any new transfers, > independent of when the assignment was made, to avoid a rush on the > NCC for new memberships. +1 :-) (Now we're entering shedpainting land - "all /24s? all /24s allocated from the wait queue in 2021? all /24s and all previously allocated /22s?" - I'd go for "/24s allocated after Jan 1st 2021", as anything more harsh will be hard to get consensus on) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From randy at psg.com Tue Dec 7 18:28:22 2021 From: randy at psg.com (Randy Bush) Date: Tue, 07 Dec 2021 09:28:22 -0800 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: > I think that I speak for the WG, that the intent for the final /8 > policy and the waitinglist policy, is to provide IPv4 (at least a > small bit) to newcomers as a co-author of that polocy, my memory is indeed the intent was to allow newcomers to get a small bit of space for as long as possible. > If a change would be desired by the WG, it should go through the PDP, > meaning that a policy change would be required. > > - 42 (13%) are from members with 2-4 LIRs accounts > - 45 (14%) are from members with 5-9 LIR accounts > - 157 (48%) are from members with 10 or more LIR accounts this inclines me to offer to work with others on an update to the policy. gert's suggestion is interesting. randy From gert at space.net Tue Dec 7 18:31:13 2021 From: gert at space.net (Gert Doering) Date: Tue, 7 Dec 2021 18:31:13 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> Message-ID: Hi, On Tue, Dec 07, 2021 at 06:25:21PM +0100, denis walker wrote: > Many years ago I questioned why we ever invented a market for address > space 'that no one owns' when we had a perfectly good system of > allocating address space based on need and when no longer needed was > returned to the RIR to be re-allocated...for free. I was told 'don't > be silly, people will still sell the address space but not record the > transfers in the RIPE Database'. So the quality of the registry > diminishes. What is going to stop people selling these 'never to be > transferred' allocations and not recording the transfer in the RIPE > Database? I am sure some back door dealings can be arranged to keep > the LIRs active that have the allocations registered and obfuscate the > fee payments to confuse the RIPE NCC. Have companies developed some > sense of morality in recent years? If the LIR fee is still to be paid, this is commercially not very attractive - and as such, should stop the business model "open a LIR, get a /24 for EUR, sell it for <5*x>" nicely. Note that we always acknowledged the need for a block of addresses to "change hands", by mergers & acquisition. Having a formal transfer policy was basically just accepting that people would hide this in a company sale otherwise. My proposal is actually to disallow transfers *including* disallowing M&A transfers on these. It MUST stay in the LIR it was requested by, and if the LIR closes, it MUST be returned. Buying a "company with the LIR" would still be possible, of course (and I do not see a way to disallow this, it's like MS trying to disallow selling used windows licenses), but "... and then transferring, and closing the LIR" would not. Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From aleksey at fast-telecom.net Tue Dec 7 18:40:30 2021 From: aleksey at fast-telecom.net (Alexey Bulgakov) Date: Tue, 07 Dec 2021 20:40:30 +0300 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> Message-ID: <759541638898706@sas2-2fa759678732.qloud-c.yandex.net> An HTML attachment was scrubbed... URL: From jim at rfc1035.com Tue Dec 7 18:43:52 2021 From: jim at rfc1035.com (Jim Reid) Date: Tue, 7 Dec 2021 17:43:52 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> Message-ID: > On 7 Dec 2021, at 17:25, denis walker wrote: > > I am sure some back door dealings can be arranged to keep > the LIRs active that have the allocations registered and obfuscate the > fee payments to confuse the RIPE NCC. Have companies developed some > sense of morality in recent years? Unlikely. Especially for pretendy new LIRs that are hoping for a quick buck. However, we have to face facts. No v4 allocation scheme will ever be perfect. Some gaming and scams are inevitable. They always were. There will always be bad actors trying to find a loophole or two. In our post v4 world, we just have to suck it up. IMO here are the questions to consider: how much effort should this WG spend (waste?) tweaking policies for the last few drops of v4? how much time and money should the NCC spend on its address police? are those costs worth the benefit(s)? is any of this a productive and worthwhile thing to do? The least-worst option IMO would be to stop transfers of the final /24s from some date in the very near future. [We can?t impose that retroactively.] And have some agreed course of action for these blocks whenever it turns out they later change hands. From ripe-lists at sebastian-graf.at Tue Dec 7 18:44:28 2021 From: ripe-lists at sebastian-graf.at (Sebastian-Wilhelm Graf) Date: Tue, 7 Dec 2021 18:44:28 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> Message-ID: <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Hello! Any good solution should be start taking effect in the future rather than retroactively, it should be fair and transparent,... So I would like to propose two solutions to this dilemma: a) All ipv4 resources received from the the waiting list requests submitted after 2022-01-01 are non-transferable and bound to the LIR that has requested the resource. b) All ipv4 resources received from the the waiting list requests submitted after 2022-01-01 are non-transferable for the next 60 months. Suggestion (b) would bring us more in line with how ARIN handles requests. Whereas #1 would favor small LIR's. Both solutions create almost 0 additional strain on the current processes. kind regards Sebastian Graf This has the advantage of being "fair" On 12/7/21 18:31, Gert Doering wrote: > Hi, > > On Tue, Dec 07, 2021 at 06:25:21PM +0100, denis walker wrote: >> Many years ago I questioned why we ever invented a market for address >> space 'that no one owns' when we had a perfectly good system of >> allocating address space based on need and when no longer needed was >> returned to the RIR to be re-allocated...for free. I was told 'don't >> be silly, people will still sell the address space but not record the >> transfers in the RIPE Database'. So the quality of the registry >> diminishes. What is going to stop people selling these 'never to be >> transferred' allocations and not recording the transfer in the RIPE >> Database? I am sure some back door dealings can be arranged to keep >> the LIRs active that have the allocations registered and obfuscate the >> fee payments to confuse the RIPE NCC. Have companies developed some >> sense of morality in recent years? > If the LIR fee is still to be paid, this is commercially not very > attractive - and as such, should stop the business model "open a LIR, > get a /24 for EUR, sell it for <5*x>" nicely. > > Note that we always acknowledged the need for a block of addresses > to "change hands", by mergers & acquisition. Having a formal transfer > policy was basically just accepting that people would hide this in > a company sale otherwise. > > My proposal is actually to disallow transfers *including* disallowing > M&A transfers on these. It MUST stay in the LIR it was requested by, > and if the LIR closes, it MUST be returned. > > Buying a "company with the LIR" would still be possible, of course > (and I do not see a way to disallow this, it's like MS trying to > disallow selling used windows licenses), but "... and then transferring, > and closing the LIR" would not. > > Gert Doering > -- NetMaster > From gert at space.net Tue Dec 7 19:35:20 2021 From: gert at space.net (Gert Doering) Date: Tue, 7 Dec 2021 19:35:20 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <759541638898706@sas2-2fa759678732.qloud-c.yandex.net> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <759541638898706@sas2-2fa759678732.qloud-c.yandex.net> Message-ID: Hi, On Tue, Dec 07, 2021 at 08:40:30PM +0300, Alexey Bulgakov wrote: > Hi,

And what is Gert's role in RIPE NCC now?

--
Regards, Alex

19:31, 7 ?????????????? 2021 ??., Gert Doering <gert at space.net>:

Hi,

On Tue, Dec Somewhat hard to make out your question in this mess of top-quoted HTML ugliness. I never had a role in the NCC, and since I passed on the chairing hat, I no longer have a formal role in any of the working groups of RIPE. I continue to be a user of address resources, operator of routers that do care about routing table size, and advocate of letting IPv4 die and using IPv6 instead of bickering around deck chairs. But people seem to prefer the expensive before the unknown... Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ripedenis at gmail.com Tue Dec 7 20:53:52 2021 From: ripedenis at gmail.com (denis walker) Date: Tue, 7 Dec 2021 20:53:52 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: On Tue, 7 Dec 2021 at 18:44, Sebastian-Wilhelm Graf wrote: > > Hello! > > > This has the advantage of being "fair" > This depends on your definition of fairness. Let's be brutally honest here. Anyone who has set up 10, 20, 30 LIRs in the last couple of years and has received multiple /24s is intentionally circumventing the goal of the policy for financial gain. They are playing games for profit. Let's get the legal advice we need and stop these games. These are policies, not national/international laws. Policies are a set of rules for the RIPE NCC membership. Members have signed contracts agreeing to all policies and agreed changes to those policies. Nothing says a policy change cannot be retroactive. As Gert said, let's apply a policy change back to 1/1/21. If someone wants to challenge it in court...let them name and shame themselves. As a community/membership we should be willing to stand by our principles of fairness and let the RIPE NCC go to court to defend these principles. While IPv4 is still in use and essential for genuine new startup businesses, let's stand up to those who are playing these games for profit...for the good of the internet. I don't know who any of these people are with multiple LIRs. But I am sure they are all subscribed to this mailing list and will do what they can to prevent policy changes that stop them from making profits. To re quote Daniel's famous phrase at the Database BoF, "Let's stop tinkering around the edges" of these policies, jump in at the deep end and fix the problem...to stop the blatant profiteering. I am going to go one step further than Gert's proposal. Let's suspend the current policy pending a review. In other words, freeze the allocation of /24s. I am sure there is nothing in the PDP or anywhere else that allows for this. But there probably is nothing that disallows it either. Again let's have a legal review and take bold action. I am probably going to get hammered for saying all this, but sometimes we need to make bold moves and set new precedences... cheers denis co-chair DB-WG From Adrian.Bolster at purebroadband.net Tue Dec 7 21:27:07 2021 From: Adrian.Bolster at purebroadband.net (Adrian Bolster) Date: Tue, 7 Dec 2021 20:27:07 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at>, Message-ID: <6694C5DE-9C8E-4532-9BC2-C14F6BEE9ADE@purebroadband.net> Whilst I agree with the vast majority of your email it is absurd to retrospectively apply a newly adopted policy. I believe this would be a very unhealthy precedent to set. Regards, Adrian. Sent from my iPhone > On 7 Dec 2021, at 19:54, denis walker wrote: > > ?On Tue, 7 Dec 2021 at 18:44, Sebastian-Wilhelm Graf > wrote: >> >> Hello! >> >> >> This has the advantage of being "fair" >> > This depends on your definition of fairness. Let's be brutally honest > here. Anyone who has set up 10, 20, 30 LIRs in the last couple of > years and has received multiple /24s is intentionally circumventing > the goal of the policy for financial gain. They are playing games for > profit. Let's get the legal advice we need and stop these games. These > are policies, not national/international laws. Policies are a set of > rules for the RIPE NCC membership. Members have signed contracts > agreeing to all policies and agreed changes to those policies. Nothing > says a policy change cannot be retroactive. As Gert said, let's apply > a policy change back to 1/1/21. If someone wants to challenge it in > court...let them name and shame themselves. As a community/membership > we should be willing to stand by our principles of fairness and let > the RIPE NCC go to court to defend these principles. While IPv4 is > still in use and essential for genuine new startup businesses, let's > stand up to those who are playing these games for profit...for the > good of the internet. > > I don't know who any of these people are with multiple LIRs. But I am > sure they are all subscribed to this mailing list and will do what > they can to prevent policy changes that stop them from making profits. > To re quote Daniel's famous phrase at the Database BoF, "Let's stop > tinkering around the edges" of these policies, jump in at the deep end > and fix the problem...to stop the blatant profiteering. > > I am going to go one step further than Gert's proposal. Let's suspend > the current policy pending a review. In other words, freeze the > allocation of /24s. I am sure there is nothing in the PDP or anywhere > else that allows for this. But there probably is nothing that > disallows it either. Again let's have a legal review and take bold > action. > > I am probably going to get hammered for saying all this, but sometimes > we need to make bold moves and set new precedences... > > cheers > denis > co-chair DB-WG > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From gert at space.net Tue Dec 7 22:03:41 2021 From: gert at space.net (Gert Doering) Date: Tue, 7 Dec 2021 22:03:41 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <6694C5DE-9C8E-4532-9BC2-C14F6BEE9ADE@purebroadband.net> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> <6694C5DE-9C8E-4532-9BC2-C14F6BEE9ADE@purebroadband.net> Message-ID: Hi, On Tue, Dec 07, 2021 at 08:27:07PM +0000, Adrian Bolster wrote: > Whilst I agree with the vast majority of your email it is absurd > to retrospectively apply a newly adopted policy. I believe this > would be a very unhealthy precedent to set. Strictly speaking, all transfer policies have been applied retroactively (at some point, transfers were made possible for all resources that had been allocated or assigned before that point). Also, we have done this when increasing the holding period for the /22s to 24 months - which, of course, people that made money of doing fast-LIRs did not like. So this has been done and can be done again. What we cannot do is retroactively disallow a transfer that has already been *done*, but deciding new policies for existing allocations and assignment is fully covered by the RIPE general service agreement. Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From chris at semihuman.com Tue Dec 7 22:25:04 2021 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 7 Dec 2021 13:25:04 -0800 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: > On Dec 7, 2021, at 11:53 AM, denis walker wrote: > > I am going to go one step further than Gert's proposal. Let's suspend > the current policy pending a review. In other words, freeze the > allocation of /24s. I am sure there is nothing in the PDP or anywhere > else that allows for this. But there probably is nothing that > disallows it either. Again let's have a legal review and take bold > action. > I?m not going to speculate on whether or not this is warranted in this particular case - I won?t claim to have the deep understanding necessary - I will note that there is precedent for this; this course of action is functionally identical to the emergency policy that the ARIN Board Of Trustees put into place in February 2019 that suspended waiting list allocations in the region, as a direct result of the waiting list abuse discovered which seems very similar to the abuse being alleged in this thread. https://www.arin.net/vault/announcements/2019/20190207_waitlist.html That said, the current RIPE waiting list policy seems very similar to the policy that ARIN put into place when reverting the suspension, except for a shorter transfer suspension window (24 months as opposed to ARIN?s 5 year restriction on waiting list resources). So it?s not clear if further policy restrictions would solve this problem, as opposed to active investigation of request patterns that appear suspicious when held up to scrutiny. > I am probably going to get hammered for saying all this, but sometimes > we need to make bold moves and set new precedences... > Ideally, sufficient scrutinization of waiting list requests could result in the exposure of abusive patterns and bad actors, similar to the scrutiny that led to the discovery of the Micfo fraud. But that?s like saying that that we should have zero crime in a city because we have a police department. > cheers > denis > co-chair DB-WG > Thanks, -Chris > -- > > 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: From ripedenis at gmail.com Tue Dec 7 22:28:38 2021 From: ripedenis at gmail.com (denis walker) Date: Tue, 7 Dec 2021 22:28:38 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> <6694C5DE-9C8E-4532-9BC2-C14F6BEE9ADE@purebroadband.net> Message-ID: On Tue, 7 Dec 2021 at 22:03, Gert Doering wrote: > > Hi, > > On Tue, Dec 07, 2021 at 08:27:07PM +0000, Adrian Bolster wrote: > > Whilst I agree with the vast majority of your email it is absurd > > to retrospectively apply a newly adopted policy. I believe this > > would be a very unhealthy precedent to set. Despite the fact this precedence has already been set, as Gert explained, why do you think it is absurd? These people are bending the rules for profit against the interests of the industry. Let's bend the rules back and stop them making a profit and maybe even lose money from the fees they have already paid trying to profiteer. We should use any available option that is not explicitly 'disallowed' to close these loopholes. cheers denis co-chair DB-WG > > Strictly speaking, all transfer policies have been applied retroactively > (at some point, transfers were made possible for all resources that had > been allocated or assigned before that point). Also, we have done this > when increasing the holding period for the /22s to 24 months - which, > of course, people that made money of doing fast-LIRs did not like. > > So this has been done and can be done again. > > What we cannot do is retroactively disallow a transfer that has already > been *done*, but deciding new policies for existing allocations and > assignment is fully covered by the RIPE general service agreement. > > Gert Doering > -- NetMaster > -- > 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 From danny at danysek.cz Tue Dec 7 22:38:42 2021 From: danny at danysek.cz (Daniel Suchy) Date: Tue, 7 Dec 2021 22:38:42 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: <27d7be66-2ef6-2131-9bad-ab13f27f712c@danysek.cz> Hello, it seems to be a good idea to earmark new /24 IPv4 allocations as non-transferrable. It's simple from administrative point of view and clear policy for newcommers. - Daniel On 12/7/21 15:56, Gert Doering wrote: > Hi, > > On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote: >> As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution. > > As a member of the WG, I do share the sentiment that the intent of the > "IPv4 runout" policies have been "ensure that late comers to the game > can have a bit of IPv4 space, to number their IPv6 translators", and > not "grab some space for free, and sell it for more money elsewhere". > > I do not think this can be fixed on the AGM level ("one legal entity > can only have one LIR account") - we've been there, in the rush to /22s, > and all it does it "make people hide behind shell companies", so in > the end, the address space goes out anyway, but registry quality suffers. > > Trying to make the NCC require even more paperwork isn't going to stop > those that want to game the system, but will impact everyone else by > making the NCC more annoying to deal with. > > > My suggestion would be along the lines what was proposed on the APWG > meeting already - earmark these /24s as non-transferrable, ever. > > > Consequences: > > - there is no more financial incentive to "get one cheap, sell it expensive" > > - if you need space to run your business, this is exactly what it is > there for - you can still sell your business (with the /24), you > just need to keep the LIR account. But that's as with other > business assets. > > - if you want to merge multiple LIR accounts, all having their own > /24 - then you need to keep around these accounts, or return some > of the /24s. > - corrolary: if you use these /24s to number your IPv6 translators, > then renumbering this translator into "your other /24" is actually > not very hard. > - corrolary2: If you use the /24s to directly number your customers, > you missed the boat already (wearing my RIPE unicorn t-shirt today). > > Gert Doering > -- NetMaster > > From Adrian.Bolster at purebroadband.net Tue Dec 7 22:52:50 2021 From: Adrian.Bolster at purebroadband.net (Adrian Bolster) Date: Tue, 7 Dec 2021 21:52:50 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> <6694C5DE-9C8E-4532-9BC2-C14F6BEE9ADE@purebroadband.net>, Message-ID: <543E3CB1-8012-4146-A375-9714B5569E77@purebroadband.net> Was the holding time of 24 months applied retrospectively to a LIR opened prior to the policy adoption? There will be no objection to applying a retrospective rule that makes no difference or only affects individuals in a positive way. However to impose post contractual limitations after contracts have been agreed and then apply them retrospectively is in my opinion very questionable. Perhaps a better use of time and efforts is to let IPv4 die it?s inevitable death; that will force other?s hands adopting IPv6 sooner rather than later. Adrian. Sent from my iPhone On 7 Dec 2021, at 21:04, Gert Doering wrote: ?Hi, On Tue, Dec 07, 2021 at 08:27:07PM +0000, Adrian Bolster wrote: Whilst I agree with the vast majority of your email it is absurd to retrospectively apply a newly adopted policy. I believe this would be a very unhealthy precedent to set. Strictly speaking, all transfer policies have been applied retroactively (at some point, transfers were made possible for all resources that had been allocated or assigned before that point). Also, we have done this when increasing the holding period for the /22s to 24 months - which, of course, people that made money of doing fast-LIRs did not like. So this has been done and can be done again. What we cannot do is retroactively disallow a transfer that has already been *done*, but deciding new policies for existing allocations and assignment is fully covered by the RIPE general service agreement. Gert Doering -- NetMaster -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/octet-stream Size: 849 bytes Desc: signature.asc URL: From sander at steffann.nl Tue Dec 7 23:41:56 2021 From: sander at steffann.nl (Sander Steffann) Date: Tue, 7 Dec 2021 23:41:56 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: <59C5FA42-949B-4375-AE2B-16DC1675F215@steffann.nl> Hi Denis, > What is going to stop people selling these 'never to be > transferred' allocations and not recording the transfer in the RIPE > Database? The fact that the LIR can?t be closed. Having to remain a member and pay the membership fee for as long as you want to use the allocation is business as usual for people who actually want to run a network, but not for people who want to sell the space and then close the LIR. Cheers, Sander From rick at bakker-it.eu Wed Dec 8 00:49:28 2021 From: rick at bakker-it.eu (Rick Bakker) Date: Wed, 8 Dec 2021 00:49:28 +0100 Subject: [address-policy-wg] IPv4 waiting list policy Message-ID: Dear colleagues, While it is really interesting to see that the waiting list is primarily used as a means of extension for existing LIRs, it would be rather more interesting to look at the current size of the respective LIRs. It makes a lot of sense for a small LIR holding a single /24 to open a second and request a secondary /24. Effectively, holding a /23 worth of IPv4 space is still negligible in comparison to some of our fellow LIRs holding a trifold of that. It seems a countermeasure to restrict every single new /24 allocation in terms of a transfer. It will only prevent new colleagues in order for them to grow and excel in their various new concepts. I would personally strongly advocate restrictions, but only for those who already ?hold a lot?. It is simply unfair to limit new entrepreneurs in their ventures by throwing monetary bars that hold them back in potential growth. This will only really benefit the bigger colleagues among us, as the new small ?fish? are unable to compete because they lack resources to deliver a proper alternative. As such, I would rather propose a maximum amount of /24s (through new memberships) to be requested through the current waiting list policy by a single entity in a given time frame. It is not unrealistic to limit this at a single /24 per e.g. six months. This would result throwing the real ?hoarders? under the bus, by not facilitating their hunger for obtaining IPv4 ?at the cheap?, while still allowing ?legitimate? new members to grow by allocating them the resources they need. Also, let?s not forget that while the IPv4 waiting list hands out IPv4 from the RIPE NCC ?free? pool, the amount of IPv4 that is recovered is very limited and will probably be even more limited in the foreseeable future. It would make a lot more sense to push at recovering more space, that can than be handed to new colleagues in a more fair, somewhat more restrictive way. Just by looking at some public looking glasses, I can find examples of hobbyist / amateur associations that hold a /16, while it seems not nearly a quarter of that is in active use. While it has been rejected a lot of times before, and another shot at it likely won?t make a difference, the real way to recover IPv4 space, seems to be by putting monetary sanctions on free space. Think of this in terms of changing the way the RIPE NCC does their billing. At current, every single LIR, no matter its size, pays the same contribution towards our association. This policy does NOT push fellow members into returning space they no longer need, or won?t need in the foreseeable future, as holding it does not cost anything. When replacing the current billing scheme into a more flexible billing scheme where each individual IPv4 held can and will be billed, the organisations that do not need the space will return the free space. After all: why pay for resources that you do not need, and won?t need? Of course, for smaller LIRs, this impact won?t be significant. But picture a LIR holding several /16s, of which only a couple of /24 prefixes are in active use? At a small fee of say 10 euro cents per IPv4 address, returning half of a /16, would mean an annual reduction of costs by 6K. Such amount is not that significant, but big enough to push smaller LIRs that hold such an amount of unused space, to return the unused parts. Such a policy could free up a lot of unused space that can then be redistributed to our new colleagues through a more restrictive waiting list mechanism. In this current discussion, some of our fellow colleagues have a tendency to ignore identifying a problem, because they believe IPv4 will ?die? on a short term. Let?s face it: at current, a proper hosting service cannot be delivered without IPv4. Of course, there is a steady growth to be identified in global IPv6 usage, this does not mean we can simply have new colleagues ?wait? another ten years or so before their IPv6-only services can be seen as mature enough for production use. To wrap up my argument: the sole way of resolving this matter is by having the older LIRs be lenient enough to help recover space by returning it, and redistributing it in a fair manner. It is often said that. The current ?guild? of network engineers like to see the next generation grow up, and show interest in their very interesting field. I, myself, at the young age of 21, identify myself as such. But without any leniency from their end to help give everyone a fair chance at starting their own online ventures, by means of allocating at least the most essential resources for them to get going, this will only get harder and harder in the years to come. Yes, my stance will generate a lot of resistance, I am sure, by exactly the group I mentioned that will in this matter show a lack of lenience. But please, all, let?s take a stance that is serious and will help us all along in times of the ?real-real-real? scarce of IPv4 in our service region. Regards, Rick Bakker -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at interall.co.il Wed Dec 8 07:11:17 2021 From: hank at interall.co.il (Hank Nussbacher) Date: Wed, 8 Dec 2021 08:11:17 +0200 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: <75bcbccf-3229-82be-e7dd-a49527ced8a5@interall.co.il> On 07/12/2021 16:56, Gert Doering wrote: > Hi, > > Trying to make the NCC require even more paperwork isn't going to stop > those that want to game the system, but will impact everyone else by > making the NCC more annoying to deal with. > > My suggestion would be along the lines what was proposed on the APWG > meeting already - earmark these /24s as non-transferrable, ever. +1 -Hank From arash_mpc at parsun.com Wed Dec 8 07:51:45 2021 From: arash_mpc at parsun.com (Arash Naderpour) Date: Wed, 8 Dec 2021 17:51:45 +1100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: Hi, >I think that I speak for the WG, that the intent for the final /8 policy and the waitinglist policy, is to provide IPv4 (at least a small bit) to newcomers .. meaning that how it currently works and how it was >intended .. that this might not align with what the WG initially wanted. A newcomer can still apply to get an /24 with the current policy, being in a waiting list means you need to wait (it aligns with the current policy). there was no intention to have a fast track or a definite waiting period to get the /24. If a newcomer needs IPv4 urgently they can request an existing member to transfer IP address to them, looking at transfer statistics we can see that there are many v4 transfers happening every month. Maybe better to find a way to push old members to return their free IPv4 blocks to have more free IP in the pool? This can be done by a change to the current billing method but that needs to be decided by NCC members, not the WG. Regards, Arash On Wed, Dec 8, 2021 at 1:29 AM Erik Bais wrote: > Hi Marco, > > Thank you for the detailed information of the dispersion about the current > and past of the waitinglist. > > To the WG: > > The current workings of the IPv4 Waitinglist is specified in the IPv4 > Address Allocation and Assignment Policies for the RIPE NCC Service Region > > https://www.ripe.net/publications/docs/ripe-733#5 > > Currently there is a First Come First Serve procedure for the waitinglist > .. and there are no limitation to allocating v4 space to members that have > been already allocated v4 space since the waitinglist started. > > I think that I speak for the WG, that the intent for the final /8 policy > and the waitinglist policy, is to provide IPv4 (at least a small bit) to > newcomers .. meaning that how it currently works and how it was intended .. > that this might not align with what the WG initially wanted. > > If a change would be desired by the WG, it should go through the PDP, > meaning that a policy change would be required. > > As WG chairs we would like to see the position of the WG on the topic and > what could be seen as a possible solution. > > Regards, > Erik Bais > On behalf of the AP-WG Co-Chair collective. > > > > ?On 07/12/2021, 10:23, "address-policy-wg on behalf of Marco Schmidt" < > address-policy-wg-bounces at ripe.net on behalf of mschmidt at ripe.net> wrote: > > Dear colleagues, > > In the Address Policy Working Group sessions at RIPE 83, I shared our > observations regarding the IPv4 waiting list policy. [1] > > The intent of this policy was to provide newcomers with a minimal > amount > of IPv4 space for as long as possible. However, about half of these > allocations went to members that received several /24 allocations via > multiple LIR accounts. > > As there was interest in reviewing the policy at the RIPE Meeting, I > would like to provide more detail on the provision of IPv4 allocations > over the last two years and the current situation with the waiting > list. > > In the last 24 months, we provided 4,178 LIRs with a /24 allocation: > - 2,019 allocations (48%) went to members with a single LIR account > - 452 allocations (11%) went to members with 2-4 LIR accounts > - 298 allocations (7%) went to members with 5-9 LIR accounts and > - 1,409 allocations (34%) went to members with 10 or more LIR > accounts (up to 33 /24 allocations to a single member) > > This trend towards allocations to multiple LIR accounts has > accelerated > in the past six months. Between June and November 2021, only 24% of > allocations went to members with a single LIR account, while 54% went > to > members with 10 or more accounts. > > We see the same trend with the current waiting list. At the time of > writing, we can see 327 requests for a /24 allocation: > - 83 (25%) are from members with a single LIR account > - 42 (13%) are from members with 2-4 LIRs accounts > - 45 (14%) are from members with 5-9 LIR accounts > - 157 (48%) are from members with 10 or more LIR accounts > > Consequently, there is a significantly longer wait time for members > with > a single LIR account. > > Looking at the current market prices for IPv4 in comparison to our > membership fees, even a wait time of several months is acceptable for > organisations that plan to transfer their allocation after the end of > the holding period. Conversely, the long wait time will create > uncertainty for real newcomers, especially if they can?t rely on > IPv6-only networks. > > I hope the WG finds this information useful for further discussion. If > there is consensus to change the current situation, there are several > approaches available ? including a review of the waiting list policy > and > changing ?per LIR? to something else. Other approaches, such as a > different charging scheme or changing the concept of multiple LIRs > would > need to be approved by the RIPE NCC membership. > > Kind regards, > Marco Schmidt > Assistant Manager Registry Services > RIPE NCC > > [1] https://ripe83.ripe.net/archives/video/642/ > > > -- > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ > > > -- > > 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: From arash_mpc at parsun.com Wed Dec 8 08:03:53 2021 From: arash_mpc at parsun.com (Arash Naderpour) Date: Wed, 8 Dec 2021 18:03:53 +1100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: >My suggestion would be along the lines what was proposed on the APWG >meeting already - earmark these /24s as non-transferrable, ever. I don't think it is a good idea to split the IPv4 addresses into different types, transferable and non-transferrable. it puts those newcomers in a disadvantageous position compared to the older members, it is not fair and doesn't fix anything in long term. Regards, Arash On Wed, Dec 8, 2021 at 1:56 AM Gert Doering wrote: > Hi, > > On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote: > > As WG chairs we would like to see the position of the WG on the topic > and what could be seen as a possible solution. > > As a member of the WG, I do share the sentiment that the intent of the > "IPv4 runout" policies have been "ensure that late comers to the game > can have a bit of IPv4 space, to number their IPv6 translators", and > not "grab some space for free, and sell it for more money elsewhere". > > I do not think this can be fixed on the AGM level ("one legal entity > can only have one LIR account") - we've been there, in the rush to /22s, > and all it does it "make people hide behind shell companies", so in > the end, the address space goes out anyway, but registry quality suffers. > > Trying to make the NCC require even more paperwork isn't going to stop > those that want to game the system, but will impact everyone else by > making the NCC more annoying to deal with. > > > My suggestion would be along the lines what was proposed on the APWG > meeting already - earmark these /24s as non-transferrable, ever. > > > Consequences: > > - there is no more financial incentive to "get one cheap, sell it > expensive" > > - if you need space to run your business, this is exactly what it is > there for - you can still sell your business (with the /24), you > just need to keep the LIR account. But that's as with other > business assets. > > - if you want to merge multiple LIR accounts, all having their own > /24 - then you need to keep around these accounts, or return some > of the /24s. > - corrolary: if you use these /24s to number your IPv6 translators, > then renumbering this translator into "your other /24" is actually > not very hard. > - corrolary2: If you use the /24s to directly number your customers, > you missed the boat already (wearing my RIPE unicorn t-shirt today). > > Gert Doering > -- NetMaster > -- > 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: From david.ponzone at ipeva.fr Wed Dec 8 08:33:38 2021 From: david.ponzone at ipeva.fr (David Ponzone) Date: Wed, 8 Dec 2021 08:33:38 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: Personally, I would suggest to increase the 2-years-period if the resulting merged LIR contains prefixes from 2 merged LIRs or more Example: A (has a /24) and B (has one historical /22 and another /22 from a previous merger) wants to merge: they would need to wait 3 years. Next time, It would be 4 years, etc? Also, if several mergers with the same LIR are requested, I honestly don?t recall if this is allowed, but it should not: one merge per LIR per year. That should block serial-mergers, but not regular small LIRs with a real network activity. There are probably loop-holes in my idea, or it?s perhaps too complex to implement. David Ponzone Direction Technique email: david.ponzone at ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pi?ces jointes sont confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autoris?e est interdite. Tout message ?lectronique est susceptible d'alt?ration. IPeva d?cline toute responsabilit? au titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?. Si vous n'?tes pas destinataire de ce message, merci de le d?truire imm?diatement et d'avertir l'exp?diteur. > Le 8 d?c. 2021 ? 08:03, Arash Naderpour a ?crit : > > >My suggestion would be along the lines what was proposed on the APWG > >meeting already - earmark these /24s as non-transferrable, ever. > > I don't think it is a good idea to split the IPv4 addresses into different types, transferable and non-transferrable. it puts those newcomers in a disadvantageous position compared to the older members, it is not fair and doesn't fix anything in long term. > > Regards, > > Arash > > > > > On Wed, Dec 8, 2021 at 1:56 AM Gert Doering > wrote: > Hi, > > On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote: > > As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution. > > As a member of the WG, I do share the sentiment that the intent of the > "IPv4 runout" policies have been "ensure that late comers to the game > can have a bit of IPv4 space, to number their IPv6 translators", and > not "grab some space for free, and sell it for more money elsewhere". > > I do not think this can be fixed on the AGM level ("one legal entity > can only have one LIR account") - we've been there, in the rush to /22s, > and all it does it "make people hide behind shell companies", so in > the end, the address space goes out anyway, but registry quality suffers. > > Trying to make the NCC require even more paperwork isn't going to stop > those that want to game the system, but will impact everyone else by > making the NCC more annoying to deal with. > > > My suggestion would be along the lines what was proposed on the APWG > meeting already - earmark these /24s as non-transferrable, ever. > > > Consequences: > > - there is no more financial incentive to "get one cheap, sell it expensive" > > - if you need space to run your business, this is exactly what it is > there for - you can still sell your business (with the /24), you > just need to keep the LIR account. But that's as with other > business assets. > > - if you want to merge multiple LIR accounts, all having their own > /24 - then you need to keep around these accounts, or return some > of the /24s. > - corrolary: if you use these /24s to number your IPv6 translators, > then renumbering this translator into "your other /24" is actually > not very hard. > - corrolary2: If you use the /24s to directly number your customers, > you missed the boat already (wearing my RIPE unicorn t-shirt today). > > Gert Doering > -- NetMaster > -- > 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/ > -- > > 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: From gert at space.net Wed Dec 8 08:39:51 2021 From: gert at space.net (Gert Doering) Date: Wed, 8 Dec 2021 08:39:51 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <543E3CB1-8012-4146-A375-9714B5569E77@purebroadband.net> References: <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> <6694C5DE-9C8E-4532-9BC2-C14F6BEE9ADE@purebroadband.net> <543E3CB1-8012-4146-A375-9714B5569E77@purebroadband.net> Message-ID: Hi, On Tue, Dec 07, 2021 at 09:52:50PM +0000, Adrian Bolster wrote: > Was the holding time of 24 months applied retrospectively to a LIR opened prior to the policy adoption? All policy changes are applied uniformly to all resource holders and to all resources held. So, yes. Transfer policy changes apply to all future *transfers* only, of course, but not only to resources allocated/assigned after this point in time. (This is no different from a country changing its VAT on second hand car sales - that will apply to all car sales from that point on, no matter when the car to be sold has been bought) Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gert at space.net Wed Dec 8 08:41:45 2021 From: gert at space.net (Gert Doering) Date: Wed, 8 Dec 2021 08:41:45 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: Hi, On Wed, Dec 08, 2021 at 06:03:53PM +1100, Arash Naderpour wrote: > >My suggestion would be along the lines what was proposed on the APWG > >meeting already - earmark these /24s as non-transferrable, ever. > > I don't think it is a good idea to split the IPv4 addresses into different > types, transferable and non-transferrable. it puts those newcomers in a > disadvantageous position compared to the older members, it is not fair and > doesn't fix anything in long term. Actually, the point is to have something to offer to the newcomers. If we do not stop the hoarding *now*, there won't be any IPv4 left - would that be "more fair" to the newcomers? I wouldn't mind a policy that says "The RIPE NCC does no longer deal in IPv4 resources at all. Everything coming back into the RIPE NCC free pool is returned to IANA." - that would be maximally *fair* (the same amount of nothing for everybody), but I assume you wouldn't like that either. Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From frettled at gmail.com Wed Dec 8 09:02:31 2021 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 8 Dec 2021 09:02:31 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: This is a good discussion, and a good discussion to have. On Tue, Dec 7, 2021 at 8:54 PM denis walker wrote: > As Gert said, let's apply > a policy change back to 1/1/21. If someone wants to challenge it in > court...let them name and shame themselves. As a community/membership > we should be willing to stand by our principles of fairness and let > the RIPE NCC go to court to defend these principles. While IPv4 is > still in use and essential for genuine new startup businesses, let's > stand up to those who are playing these games for profit...for the > good of the internet. > > > ... I am going to go one step further than Gert's proposal. Let's suspend > the current policy pending a review. In other words, freeze the > allocation of /24s. I am sure there is nothing in the PDP or anywhere > else that allows for this. But there probably is nothing that > disallows it either. Again let's have a legal review and take bold > action. > These suggestions seem to combine nicely with a 60-month block on transfers (including M&A) or permanent block of transfers (including M&A). I'm a bit hesitant regarding blocking M&A, but a 60-month block of M&A handover would probably suffice. So, to sum up what I think sounds reasonable (the list is not an "or"-list, it's an "and"-list): A) IPv4 address space allocated this year, and for the future, will be non-transferable. B) IPv4 address space allocated this year, and for the future, will not be transferable via M&A for 60 months after allocation. C) IPv4 waiting list priority follows the size of existing allocations for the LIR. The lower amount of allocations, starting with zero, the higher the priority. The next priorty level can gain resources if an only if noone of higher priority is waiting for resources. D) When considering existing allocations for prioritizing the waiting list, also consider other LIRs within the same corporate structure as the same LIR. Process steps: 1) Freeze the allocation of IPv4 address space as soon as possible. 2) Prepare new policies for allocations, transfers, and M&A. 3) Unfreeze allocation when the new policies are in place. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick at bakker-it.eu Wed Dec 8 09:17:36 2021 From: rick at bakker-it.eu (Rick Bakker) Date: Wed, 8 Dec 2021 09:17:36 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: +1 Let?s try and stop the elite formed by said old members? Also: how objective can it be said this working group is, when a prominent member himself, is part of companies that do exactly what is said to try and prevent here? Cough cough cough? Looking back at 2019, forming shell companies to obtain /22s, to merge the companies and the LIRs, only to ?broker? (hint) this exact space? This smells like actively trying to put competition into disadvantage. If you wish to fight these companies, make it hard for everyone. E.g. delay every single transfer, of any prefix. Or prevent every single transfer, no matter when the prefix was first allocated. Fair it wouldn?t be, but with an elite thinking they know best, will it ever be? Op wo 8 dec. 2021 om 08:03 schreef Arash Naderpour > >My suggestion would be along the lines what was proposed on the APWG > >meeting already - earmark these /24s as non-transferrable, ever. > > I don't think it is a good idea to split the IPv4 addresses into different > types, transferable and non-transferrable. it puts those newcomers in a > disadvantageous position compared to the older members, it is not fair and > doesn't fix anything in long term. > > Regards, > > Arash > > > > > On Wed, Dec 8, 2021 at 1:56 AM Gert Doering wrote: > >> Hi, >> >> On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote: >> > As WG chairs we would like to see the position of the WG on the topic >> and what could be seen as a possible solution. >> >> As a member of the WG, I do share the sentiment that the intent of the >> "IPv4 runout" policies have been "ensure that late comers to the game >> can have a bit of IPv4 space, to number their IPv6 translators", and >> not "grab some space for free, and sell it for more money elsewhere". >> >> I do not think this can be fixed on the AGM level ("one legal entity >> can only have one LIR account") - we've been there, in the rush to /22s, >> and all it does it "make people hide behind shell companies", so in >> the end, the address space goes out anyway, but registry quality suffers. >> >> Trying to make the NCC require even more paperwork isn't going to stop >> those that want to game the system, but will impact everyone else by >> making the NCC more annoying to deal with. >> >> >> My suggestion would be along the lines what was proposed on the APWG >> meeting already - earmark these /24s as non-transferrable, ever. >> >> >> Consequences: >> >> - there is no more financial incentive to "get one cheap, sell it >> expensive" >> >> - if you need space to run your business, this is exactly what it is >> there for - you can still sell your business (with the /24), you >> just need to keep the LIR account. But that's as with other >> business assets. >> >> - if you want to merge multiple LIR accounts, all having their own >> /24 - then you need to keep around these accounts, or return some >> of the /24s. >> - corrolary: if you use these /24s to number your IPv6 translators, >> then renumbering this translator into "your other /24" is actually >> not very hard. >> - corrolary2: If you use the /24s to directly number your customers, >> you missed the boat already (wearing my RIPE unicorn t-shirt today). >> >> Gert Doering >> -- NetMaster > > >> -- >> 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/ >> > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://mailman.ripe.net/ > -- Kind Regards, Rick Bakker Director Bakker IT Dutch Chamber of Commerce number: 71593721 VAT registration ID: NL002414398B43 -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash_mpc at parsun.com Wed Dec 8 09:40:14 2021 From: arash_mpc at parsun.com (Arash Naderpour) Date: Wed, 8 Dec 2021 19:40:14 +1100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: >>Actually, the point is to have something to offer to the newcomers. We can update the transfer policy and transfer hold time to 60months or even more to make it less attractive, Also make a change to the policy to make no /24 allocation to multi LIR accounts. Regards, Arash On Wed, Dec 8, 2021 at 6:41 PM Gert Doering wrote: > Hi, > > On Wed, Dec 08, 2021 at 06:03:53PM +1100, Arash Naderpour wrote: > > >My suggestion would be along the lines what was proposed on the APWG > > >meeting already - earmark these /24s as non-transferrable, ever. > > > > I don't think it is a good idea to split the IPv4 addresses into > different > > types, transferable and non-transferrable. it puts those newcomers in a > > disadvantageous position compared to the older members, it is not fair > and > > doesn't fix anything in long term. > > Actually, the point is to have something to offer to the newcomers. > > If we do not stop the hoarding *now*, there won't be any IPv4 left - would > that be "more fair" to the newcomers? > > > I wouldn't mind a policy that says "The RIPE NCC does no longer deal in > IPv4 resources at all. Everything coming back into the RIPE NCC free > pool is returned to IANA." - that would be maximally *fair* (the same > amount of nothing for everybody), but I assume you wouldn't like that > either. > > Gert Doering > -- NetMaster > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arash_mpc at parsun.com Wed Dec 8 09:42:40 2021 From: arash_mpc at parsun.com (Arash Naderpour) Date: Wed, 8 Dec 2021 19:42:40 +1100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: >>If you wish to fight these companies, make it hard for everyone. E.g. delay every single transfer, of any prefix. Or prevent every single transfer, no matter when the prefix was first allocated. Fair it wouldn?t be, but with an elite thinking they know best, will it ever be? I think as long as it is for every single transfer and applied to all members, it is fair. Regards, Arash On Wed, Dec 8, 2021 at 7:17 PM Rick Bakker wrote: > +1 > > Let?s try and stop the elite formed by said old members? > > Also: how objective can it be said this working group is, when a prominent > member himself, is part of companies that do exactly what is said to try > and prevent here? Cough cough cough? > > Looking back at 2019, forming shell companies to obtain /22s, to merge the > companies and the LIRs, only to ?broker? (hint) this exact space? This > smells like actively trying to put competition into disadvantage. > > If you wish to fight these companies, make it hard for everyone. E.g. > delay every single transfer, of any prefix. Or prevent every single > transfer, no matter when the prefix was first allocated. Fair it wouldn?t > be, but with an elite thinking they know best, will it ever be? > > Op wo 8 dec. 2021 om 08:03 schreef Arash Naderpour > >> >My suggestion would be along the lines what was proposed on the APWG >> >meeting already - earmark these /24s as non-transferrable, ever. >> >> I don't think it is a good idea to split the IPv4 addresses into >> different types, transferable and non-transferrable. it puts those >> newcomers in a disadvantageous position compared to the older members, it >> is not fair and doesn't fix anything in long term. >> >> Regards, >> >> Arash >> >> >> >> >> On Wed, Dec 8, 2021 at 1:56 AM Gert Doering wrote: >> >>> Hi, >>> >>> On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote: >>> > As WG chairs we would like to see the position of the WG on the topic >>> and what could be seen as a possible solution. >>> >>> As a member of the WG, I do share the sentiment that the intent of the >>> "IPv4 runout" policies have been "ensure that late comers to the game >>> can have a bit of IPv4 space, to number their IPv6 translators", and >>> not "grab some space for free, and sell it for more money elsewhere". >>> >>> I do not think this can be fixed on the AGM level ("one legal entity >>> can only have one LIR account") - we've been there, in the rush to /22s, >>> and all it does it "make people hide behind shell companies", so in >>> the end, the address space goes out anyway, but registry quality suffers. >>> >>> Trying to make the NCC require even more paperwork isn't going to stop >>> those that want to game the system, but will impact everyone else by >>> making the NCC more annoying to deal with. >>> >>> >>> My suggestion would be along the lines what was proposed on the APWG >>> meeting already - earmark these /24s as non-transferrable, ever. >>> >>> >>> Consequences: >>> >>> - there is no more financial incentive to "get one cheap, sell it >>> expensive" >>> >>> - if you need space to run your business, this is exactly what it is >>> there for - you can still sell your business (with the /24), you >>> just need to keep the LIR account. But that's as with other >>> business assets. >>> >>> - if you want to merge multiple LIR accounts, all having their own >>> /24 - then you need to keep around these accounts, or return some >>> of the /24s. >>> - corrolary: if you use these /24s to number your IPv6 translators, >>> then renumbering this translator into "your other /24" is actually >>> not very hard. >>> - corrolary2: If you use the /24s to directly number your customers, >>> you missed the boat already (wearing my RIPE unicorn t-shirt >>> today). >>> >>> Gert Doering >>> -- NetMaster >> >> >>> -- >>> 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/ >>> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change >> your subscription options, please visit: >> https://mailman.ripe.net/ >> > -- > Kind Regards, > Rick Bakker > Director > > Bakker IT > Dutch Chamber of Commerce number: 71593721 > VAT registration ID: NL002414398B43 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hallo at ikbendiederik.nl Wed Dec 8 10:23:16 2021 From: hallo at ikbendiederik.nl (Diederik de Zee) Date: Wed, 8 Dec 2021 10:23:16 +0100 Subject: [address-policy-wg] IPv4 waiting list policy Message-ID: <138594D8-60AD-1340-88DB-686526FBAFCC@hxcore.ol> An HTML attachment was scrubbed... URL: From hallo at ikbendiederik.nl Wed Dec 8 10:23:16 2021 From: hallo at ikbendiederik.nl (Diederik de Zee) Date: Wed, 8 Dec 2021 10:23:16 +0100 Subject: [address-policy-wg] IPv4 waiting list policy Message-ID: <138594D8-60AD-1340-88DB-686526FBAFCC@hxcore.ol> An HTML attachment was scrubbed... URL: From randy at psg.com Wed Dec 8 12:26:10 2021 From: randy at psg.com (Randy Bush) Date: Wed, 08 Dec 2021 03:26:10 -0800 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: > C) IPv4 waiting list priority follows the size of existing allocations for > the LIR. The lower amount of allocations, starting with zero, the higher > the priority. if the purpose of new allocations is to allow entry, why would an LIR with any existing allocation be given more? randy From arash_mpc at parsun.com Wed Dec 8 12:39:06 2021 From: arash_mpc at parsun.com (Arash Naderpour) Date: Wed, 8 Dec 2021 22:39:06 +1100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Hi Marco, Could you please let me know how many organizations have 10 or more LIR accounts? Thanks, Arash Naderpour On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt wrote: > Dear colleagues, > > In the Address Policy Working Group sessions at RIPE 83, I shared our > observations regarding the IPv4 waiting list policy. [1] > > The intent of this policy was to provide newcomers with a minimal amount > of IPv4 space for as long as possible. However, about half of these > allocations went to members that received several /24 allocations via > multiple LIR accounts. > > As there was interest in reviewing the policy at the RIPE Meeting, I > would like to provide more detail on the provision of IPv4 allocations > over the last two years and the current situation with the waiting list. > > In the last 24 months, we provided 4,178 LIRs with a /24 allocation: > - 2,019 allocations (48%) went to members with a single LIR account > - 452 allocations (11%) went to members with 2-4 LIR accounts > - 298 allocations (7%) went to members with 5-9 LIR accounts and > - 1,409 allocations (34%) went to members with 10 or more LIR > accounts (up to 33 /24 allocations to a single member) > > This trend towards allocations to multiple LIR accounts has accelerated > in the past six months. Between June and November 2021, only 24% of > allocations went to members with a single LIR account, while 54% went to > members with 10 or more accounts. > > We see the same trend with the current waiting list. At the time of > writing, we can see 327 requests for a /24 allocation: > - 83 (25%) are from members with a single LIR account > - 42 (13%) are from members with 2-4 LIRs accounts > - 45 (14%) are from members with 5-9 LIR accounts > - 157 (48%) are from members with 10 or more LIR accounts > > Consequently, there is a significantly longer wait time for members with > a single LIR account. > > Looking at the current market prices for IPv4 in comparison to our > membership fees, even a wait time of several months is acceptable for > organisations that plan to transfer their allocation after the end of > the holding period. Conversely, the long wait time will create > uncertainty for real newcomers, especially if they can?t rely on > IPv6-only networks. > > I hope the WG finds this information useful for further discussion. If > there is consensus to change the current situation, there are several > approaches available ? including a review of the waiting list policy and > changing ?per LIR? to something else. Other approaches, such as a > different charging scheme or changing the concept of multiple LIRs would > need to be approved by the RIPE NCC membership. > > Kind regards, > Marco Schmidt > Assistant Manager Registry Services > RIPE NCC > > [1] https://ripe83.ripe.net/archives/video/642/ > > > -- > > 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: From tasic at academ.kiev.ua Wed Dec 8 14:31:45 2021 From: tasic at academ.kiev.ua (Taras Heichenko) Date: Wed, 8 Dec 2021 15:31:45 +0200 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: <9056D208-4825-4CD9-9EBF-C4C51CAD0960@academ.kiev.ua> Hi all, I read here long enough but usually, I do not write. Let me say just a few words. My letter is not an answer to any particular letter. It is the impression from the whole thread. I think we need to be honest with ourselves. We try to give cheaply the expensive resource. We don't have enough control to check that resource is not transferred to another recipient for money. Did you ever see that everybody follows the rules in such cases? We say that we want to give resources to newcomers almost for free but we also don't do this because of limited resources. Can you imagine a startup that just seats on the chair and wait a half of a year for the /24? (And during all this time it pays for membership without defined perspectives.) I can't. So I think there are two ways. First is selling IP addresses for their market price. I heard many times all reasons why we cannot do this. Ok. I do not try to persuade anybody to do it. I just try to be honest. The second is just to accept the [black] market of IPv4 addresses and at least try to make rules that will not cause disturbance of information in the RIPE DB (if you restrict IP transfer you just will not see this transfer in the RIPE DB but IPs will be used by another owner). BTW when we try to give IPv4 to all we slow down the IPv6 deployment. Please, do not explain to me evident things. Just be honest to yourselves. -- Taras Heichenko tasic at academ.kiev.ua From frettled at gmail.com Wed Dec 8 14:47:19 2021 From: frettled at gmail.com (Jan Ingvoldstad) Date: Wed, 8 Dec 2021 14:47:19 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: On Wed, Dec 8, 2021 at 12:26 PM Randy Bush wrote: > > C) IPv4 waiting list priority follows the size of existing allocations > for > > the LIR. The lower amount of allocations, starting with zero, the higher > > the priority. > > if the purpose of new allocations is to allow entry, why would an LIR > with any existing allocation be given more? > That would only happen if there are zero new entrants, as an LIR with any existing allocation would have a lower priority on the waiting list. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo at vegoda.org Wed Dec 8 15:09:13 2021 From: leo at vegoda.org (Leo Vegoda) Date: Wed, 8 Dec 2021 06:09:13 -0800 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <138594D8-60AD-1340-88DB-686526FBAFCC@hxcore.ol> References: <138594D8-60AD-1340-88DB-686526FBAFCC@hxcore.ol> Message-ID: Hi, The Address Policy WG cannot set policies that govern the charging scheme. That is something controlled by the RIPE NCC's membership. If you represent a RIPE NCC member, you're welcome to make proposals related to the charging scheme on the Membership Discuss mailing list: https://www.ripe.net/participate/member-support/membership-mailing-lists/subscribing-to-members-discuss Kind regards, Leo Vegoda, for the Address Policy WG co-chairs On Wed, Dec 8, 2021 at 1:24 AM Diederik de Zee wrote: > > Dear members, > > I agree with the post of R. Bakker @ Dec 8 00:49:28 CET 2021 under this mailing list. > > New members should not be pushed as hard as, say, a large company with multiple huge ranges with a lot of unused IPv4 space. Incentives should be placed on the use of much IPv4, the perfect way to regulate this is to ask a monthly or yearly fee per allocated IPv4 address. > > as a example, average large DC or hosting company seems to currently hold 20 to 50% of its IPv4 space unused and keeps reserving ipv4. You will retrieve a lot of ranges if all out of a sudden it costs them thousands of euro?s each period, because that is a huge write off for them and something they can generally not afford. > > That change would cause a lot of IPv4 to be free?d up, and make more room for startups and other business that actually have good reasoning for using that ipv4 space. > > Kind regards, > Diederik de Zee > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From rick at bakker-it.eu Wed Dec 8 15:12:10 2021 From: rick at bakker-it.eu (Rick Bakker) Date: Wed, 8 Dec 2021 15:12:10 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: > That would only happen if there are zero new entrants, as an LIR with any existing allocation would have a lower priority on the waiting list. Such a policy would not fight the initial point of discussion that there are single entities requesting multiple times, or using individual legal entities. After all, Rick's IP hoarding business A BV and Rick's IP hoarding business B BV are separate legal entities, thus in your proposal being put in front of a single entity that has two requests under the same legal entity. Such policy, I think, would only push for incorporating multiple entities for the sole purpose of pushing ahead in the queue. (e.g. just look at "Network Space Provider LTD" in the British company register). All are/were held by a single UBO. Perhaps it would make sense to record UBOs (ultimate beneficial owners), and categorize the waiting list based on the amount of IPs a UBO has already received, plus limit the amount of memberships unique UBOs can open (albeit: open, with a restriction of being unable to request scarce resources). This should include pre-2012 allocations, given we're at the last stretch. and it would be weird to hand someone holding a /21 a 'final /24' when others are in a more urgent need of holding any IPs. Of course, any new policy should only be put into effect for newly made allocations, without any retrospective effects. Regards, Rick On Wed, Dec 8, 2021 at 2:47 PM Jan Ingvoldstad wrote: > > On Wed, Dec 8, 2021 at 12:26 PM Randy Bush wrote: > >> > C) IPv4 waiting list priority follows the size of existing allocations >> for >> > the LIR. The lower amount of allocations, starting with zero, the higher >> > the priority. >> >> if the purpose of new allocations is to allow entry, why would an LIR >> with any existing allocation be given more? >> > > That would only happen if there are zero new entrants, as an LIR with any > existing allocation would have a lower priority on the waiting list. > > -- > Jan > -- > > 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: From ripedenis at gmail.com Wed Dec 8 15:24:11 2021 From: ripedenis at gmail.com (denis walker) Date: Wed, 8 Dec 2021 15:24:11 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: On Wed, 8 Dec 2021 at 14:47, Jan Ingvoldstad wrote: > > > On Wed, Dec 8, 2021 at 12:26 PM Randy Bush wrote: >> >> > C) IPv4 waiting list priority follows the size of existing allocations for >> > the LIR. The lower amount of allocations, starting with zero, the higher >> > the priority. >> >> if the purpose of new allocations is to allow entry, why would an LIR >> with any existing allocation be given more? > > > That would only happen if there are zero new entrants, as an LIR with any existing allocation would have a lower priority on the waiting list. If there are no new entrants on the waiting list, the RIPE NCC should just hold on to any address space it has until there is another new entrant. I agree with Randy. The RIPE NCC should not give freely any address space to any organisation that already holds address space in ANY of it's many LIRs. If a company that already holds address space wants more they can buy it on the open market. To avoid new startup shell companies cheating the system, maybe we should go back to the needs based assessment for new startups. cheers denis > > -- > Jan > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From jim at rfc1035.com Wed Dec 8 15:40:24 2021 From: jim at rfc1035.com (Jim Reid) Date: Wed, 8 Dec 2021 14:40:24 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: > On 8 Dec 2021, at 14:12, Rick Bakker wrote: > > (e.g. just look at "Network Space Provider LTD" in the British company register). All are/were held by a single UBO. Companies House (the UK register of companies) says all of them were dissolved on Nov 16th - about three weeks ago. This news may have some bearing on whatever address resources were or weren?t obtained by those now dead firms. BTW if these firms had a single ultimate beneficial owner, it would have been trivial to obscure that fact. Just register each company with different but bogus identities. CH does not check this information. Which by implication would make it hard for the NCC to check. From rick at bakker-it.eu Wed Dec 8 16:03:43 2021 From: rick at bakker-it.eu (Rick Bakker) Date: Wed, 8 Dec 2021 16:03:43 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: > Just register each company with different but bogus identities. CH does not check this information. Which by implication would make it hard for the NCC to check. They already identify and take note of the director / authorized representative who does the application with the RIPE NCC. It wouldn't seem hard to keep track and put it to measure. Nothing is bullet-proof. That is something we just have to accept, and I believe is mentioned already multiple times in this thread alone. That does not mean trivial options shall simply be disqualified for that sole matter. That it isn't 100% effective, does not mean that it does not filter out at least some of the scum. If we can at least filter the most ruthless, that might just free up enough IPv4 space to keep enough supply to feed new entrants. We should not push at trying to make it as hard as possible for new entrants to join, rather push at enforcing guidelines to make sure it is not abused (at least not to a certain extent). It is unjustifiable to refuse a startup to hold 2x /24 if they can justify a use technically, when more established entities within our association hold more than a trifold of such an allocation. Please: encourage new entrepreneurship, do not crush them 'to the ground'. Also: how to deal with some in the addressing-wg chair being active in 'hoarding' allocations? It seems to me that said (co-)chair would have to recuse himself from any involvement in this matter, as it indirectly is influenced by his business in mind? After all, if said (co-)chair can make it harder for new entrants to obtain IPv4 space, that inherently means his brokering business can thrive from a lack of supply he can (in)directly cause? Regards, Rick On Wed, Dec 8, 2021 at 3:40 PM Jim Reid wrote: > > > > On 8 Dec 2021, at 14:12, Rick Bakker wrote: > > > > (e.g. just look at "Network Space Provider LTD" in the British > company register). All are/were held by a single UBO. > > Companies House (the UK register of companies) says all of them were > dissolved on Nov 16th - about three weeks ago. This news may have some > bearing on whatever address resources were or weren?t obtained by those now > dead firms. > > BTW if these firms had a single ultimate beneficial owner, it would have > been trivial to obscure that fact. Just register each company with > different but bogus identities. CH does not check this information. Which > by implication would make it hard for the NCC to check. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ms at uakom.sk Wed Dec 8 16:14:49 2021 From: ms at uakom.sk (Martin Stanislav) Date: Wed, 8 Dec 2021 16:14:49 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: <20211208151449.GA16632@moon> On Wed, Dec 08, 2021 at 02:40:24PM +0000, Jim Reid wrote: > > > > On 8 Dec 2021, at 14:12, Rick Bakker wrote: > > > > (e.g. just look at "Network Space Provider LTD" in the British company register). All are/were held by a single UBO. > > BTW if these firms had a single ultimate beneficial owner, it would have been trivial to obscure that fact. Just register each company with different but bogus identities. CH does not check this information. Which by implication would make it hard for the NCC to check. NCC is already spending resouces on "Know Your Customer" (KYC) efforts wrt due diligence for the quality of registration data and the sanctions. I'm by no means trying to say this is an easy or exhilarating endeavour, or that it's possible to reuse such efforts early enough to save any v4 resources for the new entrants. Martin From ripedenis at gmail.com Wed Dec 8 18:43:16 2021 From: ripedenis at gmail.com (denis walker) Date: Wed, 8 Dec 2021 18:43:16 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <20211208151449.GA16632@moon> References: <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> <20211208151449.GA16632@moon> Message-ID: Colleagues Can I suggest another approach. Instead of having a multitude of policies for IPv4 (Allocation and Assignment, Transfer, Waiting List, etc), why don't we just write a new IPv4 policy? Take the relevant and necessary bits from all other policies and add in new bits and constraints. While we do this all allocations of IPv4 from the RIPE NCC should be immediately suspended. Then we have all the rules about IPv4 in one place. Lets face it, the NCC is never going to have huge amounts of IPv4 addresses to freely hand out again. But we also know IPv6 is not going to become the dominant variant for some time yet. So let's consolidate our position on IPv4. I would suggest that the free pool of IPv4 that the RIPE NCC has from time to time should only be used to allow new startups to enter the business. Transfers on these new startup blocks should not be allowed, ever. If the new startup business is merged or acquired by a company that already hold address space then the new startup block must be returned to the RIPE NCC. If all their addresses are in use a time period can be allowed for the merged company to buy more addresses and renumber before returning the new startup block. If the merging or acquiring company holds no address space then the new company can be allowed to keep the new startup block, but the no transfer rules still apply. This should apply to all blocks allocated in the last 1 (or 2?) years. Once you are in the business, if you need more addresses you go to the market (unfortunate but that is the reality of monetising IP addresses). All efforts should be made to prevent anyone bypassing the new rules. An amnesty should be declared to allow those who have cheated the system for profit in the last couple of years to return those addresses they are currently hoarding. I am interested in the comment by Chris Woodfield about the Micfo fraud https://www.wsj.com/articles/executive-pleads-guilty-in-internet-address-fraud-case-11637101781 This raises a number of thoughts in my mind. If there are any lawyers or LEA representatives following this thread I would love to hear your views on this. Firstly, if any of these organisations that have set up multiple LIRs to obtain IP addresses for profit are based or headquartered in the USA, can the US Department of Justice bring a similar case against them as the did against Micfo for defrauding the RIPE NCC in a similar way Micfo did with ARIN? Could a similar case be brought against organisations in any part of the RIPE region by the appropriate legal authorities? Obtaining IP addresses in this way for profit prevents new companies starting up in competition with those hoarding the addresses. Certainly in the EU and the UK there are anti competitive laws. Have these laws been broken? Can the appropriate legal authorities take action against these organisations? Maybe here it would be a test case to set a new legal precedence as the Micfo case was in the USA. This is a self regulating industry. That puts constraints on what the industry can do to protect itself and show itself to regulators that it operates in a fair and openly competitive way. I am certainly in favour of pushing boundaries here and taking strong action against organisations that are behaving in a way that damages the image and operation of the industry as a whole. People often say that the RIPE NCC is not the internet police. Maybe we need to call in the real police if laws have been broken... cheers denis co-chair DB-WG On Wed, 8 Dec 2021 at 16:14, Martin Stanislav wrote: > > On Wed, Dec 08, 2021 at 02:40:24PM +0000, Jim Reid wrote: > > > > > > > On 8 Dec 2021, at 14:12, Rick Bakker wrote: > > > > > > (e.g. just look at "Network Space Provider LTD" in the British company register). All are/were held by a single UBO. > > > > BTW if these firms had a single ultimate beneficial owner, it would have been trivial to obscure that fact. Just register each company with different but bogus identities. CH does not check this information. Which by implication would make it hard for the NCC to check. > > NCC is already spending resouces on "Know Your Customer" (KYC) efforts > wrt due diligence for the quality of registration data and the sanctions. > > I'm by no means trying to say this is an easy or exhilarating endeavour, > or that it's possible to reuse such efforts early enough to save > any v4 resources for the new entrants. > > Martin > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From nick at foobar.org Wed Dec 8 19:30:42 2021 From: nick at foobar.org (Nick Hilliard) Date: Wed, 8 Dec 2021 18:30:42 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> <20211208151449.GA16632@moon> Message-ID: denis walker wrote on 08/12/2021 17:43: > I would suggest that the free pool of IPv4 that the RIPE NCC has from > time to time should only be used to allow new startups to enter the > business. Transfers on these new startup blocks should not be allowed, > ever. What your suggestion does is acknowledge that ipv4 address space has asset value. Financial value of an asset is measured either in terms of capital value (probably non-depreciable in the case of ipv4), or as an operational cost. If there's no ability to transfer the objects out of the holding company, then a block of ipv4 addresses changes from a non-depreciable fixture to an operational cost for using an asset for as long as the fees are paid, i.e. a rental arrangement. Selling the holding company is straightforward. In other words, what you're effectively proposing is that the RIPE NCC enters the ipv4 address rental market, and competes with existing market operators, with no real protection against address transfers. This may not be what you or other people intend to suggest, or want, but it is the practical outcome. Nick From randy at psg.com Wed Dec 8 19:41:37 2021 From: randy at psg.com (Randy Bush) Date: Wed, 08 Dec 2021 10:41:37 -0800 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: >>> C) IPv4 waiting list priority follows the size of existing >>> allocations for the LIR. The lower amount of allocations, starting >>> with zero, the higher the priority. >> >> if the purpose of new allocations is to allow entry, why would an LIR >> with any existing allocation be given more? > > That would only happen if there are zero new entrants, as an LIR with any > existing allocation would have a lower priority on the waiting list. i asked why, not how. imiho, the list should be for *new* entrants, period. randy From ripedenis at gmail.com Wed Dec 8 20:35:47 2021 From: ripedenis at gmail.com (denis walker) Date: Wed, 8 Dec 2021 20:35:47 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> <20211208151449.GA16632@moon> Message-ID: You have overlooked a couple of points here Nick. On Wed, 8 Dec 2021 at 19:30, Nick Hilliard wrote: > > denis walker wrote on 08/12/2021 17:43: > > I would suggest that the free pool of IPv4 that the RIPE NCC has from > > time to time should only be used to allow new startups to enter the > > business. Transfers on these new startup blocks should not be allowed, > > ever. > > What your suggestion does is acknowledge that ipv4 address space has > asset value. Financial value of an asset is measured either in terms of > capital value (probably non-depreciable in the case of ipv4), or as an > operational cost. When IPv6 becomes the dominant variant, the capital value of IPv4 depreciates to zero. Until then, address space you have bought on the open market, or were allocated prior to runout, does have a capital asset value. Holding any IPv4 addresses has an operational cost. > > If there's no ability to transfer the objects out of the holding > company, then a block of ipv4 addresses changes from a non-depreciable > fixture to an operational cost for using an asset for as long as the > fees are paid, i.e. a rental arrangement. Selling the holding company > is straightforward. This would only apply to these last dregs of address space used to allow fair competition. It does not 'change' to an operating cost. Holding any address space has an operating cost no matter how you received it. It doesn't 'change from' a non depreciable fixture as you did not pay for it. > > In other words, what you're effectively proposing is that the RIPE NCC > enters the ipv4 address rental market, and competes with existing market > operators, with no real protection against address transfers. Since it's formation the RIPE NCC has been in the address rental market. This is what it always has and continues to do. Before runout, if you wanted address space the RIPE NCC 'rented', or allocated, address space to you. The cost of the rental, or general service, agreement was the LIR fee. If you no longer needed the address space you returned it to the RIPE NCC, or rental company, and terminated your rental agreement. The RIPE NCC will not be competing with existing market operators. They can buy and sell any address space, except this tiny fragment used to allow new startups. The RIPE NCC can only rent out this last tiny fragment. cheers denis co-chair DB-WG > > This may not be what you or other people intend to suggest, or want, but > it is the practical outcome. > > Nick From nick at foobar.org Thu Dec 9 01:26:35 2021 From: nick at foobar.org (Nick Hilliard) Date: Thu, 9 Dec 2021 00:26:35 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> <20211208151449.GA16632@moon> Message-ID: <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> denis walker wrote on 08/12/2021 19:35: > Since it's formation the RIPE NCC has been in the address rental > market. This is what it always has and continues to do. The LIR fee is an association membership fee, and the RIPE NCC has taken pains over the years to emphasise that the membership fee is not linked directly to address allocation quantities, because that could be construed to be a quid-pro-quo services arrangement. Prohibiting transfers will cause the RIPE NCC to move towards a model of intrinsically linking the registration fee to a specific quantity of resources. This is because there is a fixed annual fee, and the quantity of address space is fixed if the end user acquires holdership of more than one of these /24s. I.e. if an end user has one of these /24s, they can rationalise costs by moving any existing ip address allocations into the /24 LIR, but if they have two or more of these /24s, then there is no cost advantage to doing this. If the effective rental fee is higher than market rates, then there's no value to startup end users. If it's lower, then the RIPE NCC is competing with existing market operators and potentially distorting the market, but with an effective competitive advantage in terms of having a monopoly on being able to reclaim unused ip address space from former LIRs. This would be an awkward position for the RIPE NCC to put itself into. 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. Nick From gert at space.net Thu Dec 9 08:56:48 2021 From: gert at space.net (Gert Doering) Date: Thu, 9 Dec 2021 08:56:48 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mschmidt at ripe.net Thu Dec 9 17:13:07 2021 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 9 Dec 2021 17:13:07 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Dear Arash, Thank you for your question. At the moment, we see 98 members with 10 or more LIR accounts. These members have received a total of 1254 /24s under the current IPv4 waiting list policy. I would like to note that these numbers are constantly changing. On the one hand, some members continue to open additional LIR accounts, while other members consolidate or close many LIR accounts as soon as the 24-month holding period expires. This also explains the slight difference from the previously published numbers. Several members that held 10 or more accounts when they received /24s have since reduced their number of LIRs. I hope this answers your question. Kind regards, Marco Schmidt Assistant Manager Registry Services RIPE NCC On 08/12/2021 12:39, Arash Naderpour wrote: > Hi Marco, > > Could you please let me know how many organizations have 10 or more > LIR accounts? > > Thanks, > > Arash Naderpour > > On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt wrote: > > Dear colleagues, > > In the Address Policy Working Group sessions at RIPE 83, I shared our > observations regarding the IPv4 waiting list policy. [1] > > The intent of this policy was to provide newcomers with a minimal > amount > of IPv4 space for as long as possible. However, about half of these > allocations went to members that received several /24 allocations via > multiple LIR accounts. > > As there was interest in reviewing the policy at the RIPE Meeting, I > would like to provide more detail on the provision of IPv4 > allocations > over the last two years and the current situation with the waiting > list. > > In the last 24 months, we provided 4,178 LIRs with a /24 allocation: > -??? 2,019 allocations (48%) went to members with a single LIR account > -??? 452 allocations (11%) went to members with 2-4 LIR accounts > -??? 298 allocations (7%) went to members with 5-9 LIR accounts and > -??? 1,409 allocations (34%) went to members with 10 or more LIR > accounts (up to 33 /24 allocations to a single member) > > This trend towards allocations to multiple LIR accounts has > accelerated > in the past six months. Between June and November 2021, only 24% of > allocations went to members with a single LIR account, while 54% > went to > members with 10 or more accounts. > > We see the same trend with the current waiting list. At the time of > writing, we can see 327 requests for a /24 allocation: > -??? 83 (25%) are from members with a single LIR account > -??? 42 (13%) are from members with 2-4 LIRs accounts > -??? 45 (14%) are from members with 5-9 LIR accounts > -??? 157 (48%) are from members with 10 or more LIR accounts > > Consequently, there is a significantly longer wait time for > members with > a single LIR account. > > Looking at the current market prices for IPv4 in comparison to our > membership fees, even a wait time of several months is acceptable for > organisations that plan to transfer their allocation after the end of > the holding period. Conversely, the long wait time will create > uncertainty for real newcomers, especially if they can?t rely on > IPv6-only networks. > > I hope the WG finds this information useful for further > discussion. If > there is consensus to change the current situation, there are several > approaches available ? including a review of the waiting list > policy and > changing ?per LIR? to something else. Other approaches, such as a > different charging scheme or changing the concept of multiple LIRs > would > need to be approved by the RIPE NCC membership. > > Kind regards, > Marco Schmidt > Assistant Manager Registry Services > RIPE NCC > > [1] https://ripe83.ripe.net/archives/video/642/ > > > -- > > 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: From ripedenis at gmail.com Thu Dec 9 19:29:37 2021 From: ripedenis at gmail.com (denis walker) Date: Thu, 9 Dec 2021 19:29:37 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Hi Marco I have a few more questions for you so have a clearer picture of what is going on here. -How many of these 98 members have operated the first LIR account for a number of years and held a significant amount of IPv4 address space with that account? (What I am trying to understand is if any of these members were not operating at all as an LIR before setting up this series of LIR accounts simply to obtain address space they have no intention of using but is only to sell.) -Are any of these 98 organisations transfer brokers? (I am sure it does not break any confidentiality rules to identify the type of business a group of unnamed members operate.) -Are any of these 98 organisations based in the USA? -Over what time period were their other 9 or more accounts created? -How many of these 1254 /24s have been assigned or are detectably in use? -What is the most LIRs any one member holds and how many /24s has that member obtained? -How many members have 5-9 LIRs? -How many /24s have been allocated under the waiting list policy and transferred within 6 months of the end of the 2 year holding period? This should keep your analysts busy for a while :) cheers denis co-chair DB-WG btw your document https://www.ripe.net/manage-ips-and-asns/ipv4/how-waiting-list-works references an outdated version of the IPv4 policy On Thu, 9 Dec 2021 at 17:13, Marco Schmidt wrote: > > Dear Arash, > > Thank you for your question. > > At the moment, we see 98 members with 10 or more LIR accounts. These members have received a total of 1254 /24s under the current IPv4 waiting list policy. > > I would like to note that these numbers are constantly changing. On the one hand, some members continue to open additional LIR accounts, while other members consolidate or close many LIR accounts as soon as the 24-month holding period expires. This also explains the slight difference from the previously published numbers. Several members that held 10 or more accounts when they received /24s have since reduced their number of LIRs. > > I hope this answers your question. > > Kind regards, > Marco Schmidt > Assistant Manager Registry Services > RIPE NCC > > On 08/12/2021 12:39, Arash Naderpour wrote: > > Hi Marco, > > Could you please let me know how many organizations have 10 or more LIR accounts? > > Thanks, > > Arash Naderpour > > On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt wrote: >> >> Dear colleagues, >> >> In the Address Policy Working Group sessions at RIPE 83, I shared our >> observations regarding the IPv4 waiting list policy. [1] >> >> The intent of this policy was to provide newcomers with a minimal amount >> of IPv4 space for as long as possible. However, about half of these >> allocations went to members that received several /24 allocations via >> multiple LIR accounts. >> >> As there was interest in reviewing the policy at the RIPE Meeting, I >> would like to provide more detail on the provision of IPv4 allocations >> over the last two years and the current situation with the waiting list. >> >> In the last 24 months, we provided 4,178 LIRs with a /24 allocation: >> - 2,019 allocations (48%) went to members with a single LIR account >> - 452 allocations (11%) went to members with 2-4 LIR accounts >> - 298 allocations (7%) went to members with 5-9 LIR accounts and >> - 1,409 allocations (34%) went to members with 10 or more LIR >> accounts (up to 33 /24 allocations to a single member) >> >> This trend towards allocations to multiple LIR accounts has accelerated >> in the past six months. Between June and November 2021, only 24% of >> allocations went to members with a single LIR account, while 54% went to >> members with 10 or more accounts. >> >> We see the same trend with the current waiting list. At the time of >> writing, we can see 327 requests for a /24 allocation: >> - 83 (25%) are from members with a single LIR account >> - 42 (13%) are from members with 2-4 LIRs accounts >> - 45 (14%) are from members with 5-9 LIR accounts >> - 157 (48%) are from members with 10 or more LIR accounts >> >> Consequently, there is a significantly longer wait time for members with >> a single LIR account. >> >> Looking at the current market prices for IPv4 in comparison to our >> membership fees, even a wait time of several months is acceptable for >> organisations that plan to transfer their allocation after the end of >> the holding period. Conversely, the long wait time will create >> uncertainty for real newcomers, especially if they can?t rely on >> IPv6-only networks. >> >> I hope the WG finds this information useful for further discussion. If >> there is consensus to change the current situation, there are several >> approaches available ? including a review of the waiting list policy and >> changing ?per LIR? to something else. Other approaches, such as a >> different charging scheme or changing the concept of multiple LIRs would >> need to be approved by the RIPE NCC membership. >> >> Kind regards, >> Marco Schmidt >> Assistant Manager Registry Services >> RIPE NCC >> >> [1] https://ripe83.ripe.net/archives/video/642/ >> >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From jameskennedy001 at gmail.com Thu Dec 9 20:36:08 2021 From: jameskennedy001 at gmail.com (James Kennedy) Date: Thu, 9 Dec 2021 20:36:08 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: > This should keep your analysts busy for a while :) A slightly more respectful tone for the hard work performed by the RIPE NCC analysts to answer not-so-easy questions would be appreciated, Denis. Regards, James co-chair apwg On Thu, Dec 9, 2021 at 7:30 PM denis walker wrote: > Hi Marco > > I have a few more questions for you so have a clearer picture of what > is going on here. > > -How many of these 98 members have operated the first LIR account for > a number of years and held a significant amount of IPv4 address space > with that account? > (What I am trying to understand is if any of these members were not > operating at all as an LIR before setting up this series of LIR > accounts simply to obtain address space they have no intention of > using but is only to sell.) > > -Are any of these 98 organisations transfer brokers? > (I am sure it does not break any confidentiality rules to identify the > type of business a group of unnamed members operate.) > > -Are any of these 98 organisations based in the USA? > > -Over what time period were their other 9 or more accounts created? > > -How many of these 1254 /24s have been assigned or are detectably in use? > > -What is the most LIRs any one member holds and how many /24s has that > member obtained? > > -How many members have 5-9 LIRs? > > -How many /24s have been allocated under the waiting list policy and > transferred within 6 months of the end of the 2 year holding period? > > This should keep your analysts busy for a while :) > > cheers > denis > co-chair DB-WG > > > btw your document > https://www.ripe.net/manage-ips-and-asns/ipv4/how-waiting-list-works > references an outdated version of the IPv4 policy > > On Thu, 9 Dec 2021 at 17:13, Marco Schmidt wrote: > > > > Dear Arash, > > > > Thank you for your question. > > > > At the moment, we see 98 members with 10 or more LIR accounts. These > members have received a total of 1254 /24s under the current IPv4 waiting > list policy. > > > > I would like to note that these numbers are constantly changing. On the > one hand, some members continue to open additional LIR accounts, while > other members consolidate or close many LIR accounts as soon as the > 24-month holding period expires. This also explains the slight difference > from the previously published numbers. Several members that held 10 or more > accounts when they received /24s have since reduced their number of LIRs. > > > > I hope this answers your question. > > > > Kind regards, > > Marco Schmidt > > Assistant Manager Registry Services > > RIPE NCC > > > > On 08/12/2021 12:39, Arash Naderpour wrote: > > > > Hi Marco, > > > > Could you please let me know how many organizations have 10 or more LIR > accounts? > > > > Thanks, > > > > Arash Naderpour > > > > On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt wrote: > >> > >> Dear colleagues, > >> > >> In the Address Policy Working Group sessions at RIPE 83, I shared our > >> observations regarding the IPv4 waiting list policy. [1] > >> > >> The intent of this policy was to provide newcomers with a minimal amount > >> of IPv4 space for as long as possible. However, about half of these > >> allocations went to members that received several /24 allocations via > >> multiple LIR accounts. > >> > >> As there was interest in reviewing the policy at the RIPE Meeting, I > >> would like to provide more detail on the provision of IPv4 allocations > >> over the last two years and the current situation with the waiting list. > >> > >> In the last 24 months, we provided 4,178 LIRs with a /24 allocation: > >> - 2,019 allocations (48%) went to members with a single LIR account > >> - 452 allocations (11%) went to members with 2-4 LIR accounts > >> - 298 allocations (7%) went to members with 5-9 LIR accounts and > >> - 1,409 allocations (34%) went to members with 10 or more LIR > >> accounts (up to 33 /24 allocations to a single member) > >> > >> This trend towards allocations to multiple LIR accounts has accelerated > >> in the past six months. Between June and November 2021, only 24% of > >> allocations went to members with a single LIR account, while 54% went to > >> members with 10 or more accounts. > >> > >> We see the same trend with the current waiting list. At the time of > >> writing, we can see 327 requests for a /24 allocation: > >> - 83 (25%) are from members with a single LIR account > >> - 42 (13%) are from members with 2-4 LIRs accounts > >> - 45 (14%) are from members with 5-9 LIR accounts > >> - 157 (48%) are from members with 10 or more LIR accounts > >> > >> Consequently, there is a significantly longer wait time for members with > >> a single LIR account. > >> > >> Looking at the current market prices for IPv4 in comparison to our > >> membership fees, even a wait time of several months is acceptable for > >> organisations that plan to transfer their allocation after the end of > >> the holding period. Conversely, the long wait time will create > >> uncertainty for real newcomers, especially if they can?t rely on > >> IPv6-only networks. > >> > >> I hope the WG finds this information useful for further discussion. If > >> there is consensus to change the current situation, there are several > >> approaches available ? including a review of the waiting list policy and > >> changing ?per LIR? to something else. Other approaches, such as a > >> different charging scheme or changing the concept of multiple LIRs would > >> need to be approved by the RIPE NCC membership. > >> > >> Kind regards, > >> Marco Schmidt > >> Assistant Manager Registry Services > >> RIPE NCC > >> > >> [1] https://ripe83.ripe.net/archives/video/642/ > >> > >> > >> -- > >> > >> To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://mailman.ripe.net/ > > -- > > 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: From ripedenis at gmail.com Thu Dec 9 21:19:09 2021 From: ripedenis at gmail.com (denis walker) Date: Thu, 9 Dec 2021 21:19:09 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 at 20:36, James Kennedy wrote: > > > This should keep your analysts busy for a while :) > > A slightly more respectful tone for the hard work performed by the RIPE NCC analysts to answer not-so-easy questions would be appreciated, Denis. As a former RIPE NCC analyst, who has answered many such requests in the past and is well aware of the amount of work involved, speaking to other analysts, that was not in any way intended to be disrespectful James. cheers denis co-chair DB-WG > > Regards, > James > co-chair apwg > > > > On Thu, Dec 9, 2021 at 7:30 PM denis walker wrote: >> >> Hi Marco >> >> I have a few more questions for you so have a clearer picture of what >> is going on here. >> >> -How many of these 98 members have operated the first LIR account for >> a number of years and held a significant amount of IPv4 address space >> with that account? >> (What I am trying to understand is if any of these members were not >> operating at all as an LIR before setting up this series of LIR >> accounts simply to obtain address space they have no intention of >> using but is only to sell.) >> >> -Are any of these 98 organisations transfer brokers? >> (I am sure it does not break any confidentiality rules to identify the >> type of business a group of unnamed members operate.) >> >> -Are any of these 98 organisations based in the USA? >> >> -Over what time period were their other 9 or more accounts created? >> >> -How many of these 1254 /24s have been assigned or are detectably in use? >> >> -What is the most LIRs any one member holds and how many /24s has that >> member obtained? >> >> -How many members have 5-9 LIRs? >> >> -How many /24s have been allocated under the waiting list policy and >> transferred within 6 months of the end of the 2 year holding period? >> >> This should keep your analysts busy for a while :) >> >> cheers >> denis >> co-chair DB-WG >> >> >> btw your document >> https://www.ripe.net/manage-ips-and-asns/ipv4/how-waiting-list-works >> references an outdated version of the IPv4 policy >> >> On Thu, 9 Dec 2021 at 17:13, Marco Schmidt wrote: >> > >> > Dear Arash, >> > >> > Thank you for your question. >> > >> > At the moment, we see 98 members with 10 or more LIR accounts. These members have received a total of 1254 /24s under the current IPv4 waiting list policy. >> > >> > I would like to note that these numbers are constantly changing. On the one hand, some members continue to open additional LIR accounts, while other members consolidate or close many LIR accounts as soon as the 24-month holding period expires. This also explains the slight difference from the previously published numbers. Several members that held 10 or more accounts when they received /24s have since reduced their number of LIRs. >> > >> > I hope this answers your question. >> > >> > Kind regards, >> > Marco Schmidt >> > Assistant Manager Registry Services >> > RIPE NCC >> > >> > On 08/12/2021 12:39, Arash Naderpour wrote: >> > >> > Hi Marco, >> > >> > Could you please let me know how many organizations have 10 or more LIR accounts? >> > >> > Thanks, >> > >> > Arash Naderpour >> > >> > On Tue, Dec 7, 2021 at 8:22 PM Marco Schmidt wrote: >> >> >> >> Dear colleagues, >> >> >> >> In the Address Policy Working Group sessions at RIPE 83, I shared our >> >> observations regarding the IPv4 waiting list policy. [1] >> >> >> >> The intent of this policy was to provide newcomers with a minimal amount >> >> of IPv4 space for as long as possible. However, about half of these >> >> allocations went to members that received several /24 allocations via >> >> multiple LIR accounts. >> >> >> >> As there was interest in reviewing the policy at the RIPE Meeting, I >> >> would like to provide more detail on the provision of IPv4 allocations >> >> over the last two years and the current situation with the waiting list. >> >> >> >> In the last 24 months, we provided 4,178 LIRs with a /24 allocation: >> >> - 2,019 allocations (48%) went to members with a single LIR account >> >> - 452 allocations (11%) went to members with 2-4 LIR accounts >> >> - 298 allocations (7%) went to members with 5-9 LIR accounts and >> >> - 1,409 allocations (34%) went to members with 10 or more LIR >> >> accounts (up to 33 /24 allocations to a single member) >> >> >> >> This trend towards allocations to multiple LIR accounts has accelerated >> >> in the past six months. Between June and November 2021, only 24% of >> >> allocations went to members with a single LIR account, while 54% went to >> >> members with 10 or more accounts. >> >> >> >> We see the same trend with the current waiting list. At the time of >> >> writing, we can see 327 requests for a /24 allocation: >> >> - 83 (25%) are from members with a single LIR account >> >> - 42 (13%) are from members with 2-4 LIRs accounts >> >> - 45 (14%) are from members with 5-9 LIR accounts >> >> - 157 (48%) are from members with 10 or more LIR accounts >> >> >> >> Consequently, there is a significantly longer wait time for members with >> >> a single LIR account. >> >> >> >> Looking at the current market prices for IPv4 in comparison to our >> >> membership fees, even a wait time of several months is acceptable for >> >> organisations that plan to transfer their allocation after the end of >> >> the holding period. Conversely, the long wait time will create >> >> uncertainty for real newcomers, especially if they can?t rely on >> >> IPv6-only networks. >> >> >> >> I hope the WG finds this information useful for further discussion. If >> >> there is consensus to change the current situation, there are several >> >> approaches available ? including a review of the waiting list policy and >> >> changing ?per LIR? to something else. Other approaches, such as a >> >> different charging scheme or changing the concept of multiple LIRs would >> >> need to be approved by the RIPE NCC membership. >> >> >> >> Kind regards, >> >> Marco Schmidt >> >> Assistant Manager Registry Services >> >> RIPE NCC >> >> >> >> [1] https://ripe83.ripe.net/archives/video/642/ >> >> >> >> >> >> -- >> >> >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ >> > >> > -- >> > >> > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From flo at degnet.de Fri Dec 10 04:59:26 2021 From: flo at degnet.de (Florian Fuessl) Date: Fri, 10 Dec 2021 04:59:26 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> Message-ID: <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> 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 : > > 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 > > From frettled at gmail.com Fri Dec 10 06:52:05 2021 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 10 Dec 2021 06:52:05 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> <79114B56-154C-4B92-B121-54E7E9381C2A@rfc1035.com> <61358ED8-4A6B-4E4C-B0A5-B656F013D40A@steffann.nl> <985b98f5-9a02-b2de-7f5f-24bfbebf1e8d@sebastian-graf.at> Message-ID: On Wed, Dec 8, 2021 at 7:41 PM Randy Bush wrote: > >>> C) IPv4 waiting list priority follows the size of existing > >>> allocations for the LIR. The lower amount of allocations, starting > >>> with zero, the higher the priority. > >> > >> if the purpose of new allocations is to allow entry, why would an LIR > >> with any existing allocation be given more? > > > > That would only happen if there are zero new entrants, as an LIR with any > > existing allocation would have a lower priority on the waiting list. > > i asked why, not how. imiho, the list should be for *new* entrants, > period. > If there are no new entrants, why should any available netblocks be kept unavailable for entrants who request additional netblocks? Not that I think it will ever happen ... -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathias.westerlund at wdmab.se Fri Dec 10 10:17:52 2021 From: mathias.westerlund at wdmab.se (Mathias Westerlund) Date: Fri, 10 Dec 2021 10:17:52 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> Message-ID: 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 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 : > > > > 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: From sander at steffann.nl Fri Dec 10 10:58:49 2021 From: sander at steffann.nl (Sander Steffann) Date: Fri, 10 Dec 2021 10:58:49 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> Message-ID: <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> Hi Mathias, > 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.. Don't worry, you talk about your frustration quite politely :) And it is totally justified. This is why I think something needs to be done now. Yes, it's rearranging deckchairs on the Titanic, but some people are still trying to survive. As a new member, what do you think about these ideas? Would it be good to make addresses untransferable? Or keep them transferable but ask the NCC to impose a one-time merger&acquisition fee? Or any other way? What would be ok for your real internet business but not for address sellers? Cheers, Sander From jameskennedy001 at gmail.com Fri Dec 10 13:58:51 2021 From: jameskennedy001 at gmail.com (James Kennedy) Date: Fri, 10 Dec 2021 13:58:51 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> Message-ID: Hi Mathias, Your perspective as a new LIR and experience with the IPv4 waiting is warmly welcome, thank you. Sharing these real-life stories and explaining actual impacts being felt in the community can only help our policy building and correct implementation. Would any other new LIRs like to share their stories? Or perhaps one of the members involved in merging multiple LIRs that hold /24 PA Allocations? Regards, James co-chair apwg On Fri, Dec 10, 2021 at 10:18 AM Mathias Westerlund < mathias.westerlund at wdmab.se> wrote: > 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 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 : >> > >> > 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/ >> > -- > > 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: From nick at foobar.org Sat Dec 11 01:46:45 2021 From: nick at foobar.org (Nick Hilliard) Date: Sat, 11 Dec 2021 00:46:45 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> Message-ID: Gert Doering wrote on 09/12/2021 07:56: > So, if you were to decide, what would you do? the ipv4 address market is now the largest global supplier of ipv4 addresses. To put some figures on it, 11433920 addresses were transferred via the ripe ncc in 2021 so far (ripencc-transfers_latest.json), and 9696896 in 2020. alloclist.txt shows 2981 /24 allocations so far in 2021, i.e. 763136 addresses, and 1166 /24 allocations in 2020, i.e. 298496 addresses I.e. the RIPE NCC allocated only 6.25% of the total address space which changed hands in the ripe region in 2021, and ~3% in 2020. In a market situation like this, there are two ways of making an impact: 1. by being a large enough market player that decisions you make will make a significant difference to the ecosystem and 2. by changing the rules - which RIPE / the RIPE NCC has some ability to do. The RIPE NCC has historically been reluctant to interfere with past assignments, and it's unlikely that this will change. It doesn't have the market power to change the market substantially, and any rule change it makes will only affect new allocations. In other words, a policy change from APWG, if implemented by the RIPE NCC, would only potentially affect a tiny percentage of address holdership changes, and would be unlikely to make much of a difference in the overall scheme of things. In addition to this, Marco's email mentioned: > In the last 24 months, we provided 4,178 LIRs with a /24 allocation: > - 2,019 allocations (48%) went to members with a single LIR account Allocations to members with a single LIR account are unlikely to be wholesale abusers. Some of the LIRs with multiple accounts and /24s look like genuine ip address users (e.g. telcos / vpn hosting outfits / etc). But a number of them look unusual, e.g. where the first entry on a web search for their company name is their RIPE LIR ID. > So, if you were to decide, what would you do? So, that. If I were supreme ruler of the universe, I'd get more information about these peculiar-looking allocations, then make a decision about whether it was worth either changing policy or operational practice to block or restrict allocations of this form, then model some potential options in terms of risk / outcome, and then after thinking about it for a while, I might make a decision to change policy, or executive practice, or not, depending on the overall likely outcome. Right now we don't have enough data to work with. Also, unless a fix actually fixes something, it's just busywork. Sander was right though: we're talking about rearranging the deck chairs on the Titanic, and any discussion needs to be framed in this context. Nick From randy at psg.com Sat Dec 11 03:52:42 2021 From: randy at psg.com (Randy Bush) Date: Fri, 10 Dec 2021 18:52:42 -0800 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> Message-ID: > Sander was right though: we're talking about rearranging the deck > chairs on the Titanic any betting pool on how many years the titanic will be the only viable ship of entry for newcomers? i'll take a decade. no, we don't like it. and it goes against the loudest religion. but packets gotta move; and users just want their mtv. oh little snail climb mt fuji randy From mathias.westerlund at wdmab.se Sun Dec 12 08:50:40 2021 From: mathias.westerlund at wdmab.se (Mathias Westerlund) Date: Sun, 12 Dec 2021 08:50:40 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> Message-ID: Hi again and sorry for the delayed reply. I realize it is not an easy thing to solve. I also both feel and understand that something needs to be done due to the situation at hand. The problem is that many of the solutions i would think of may include administration overhead, but i guess i will put forward two maybe three ideas. The first and easiest but that will not satisfy everyone is the most obvious one. Only allow new members to procure from the waiting list and make the addresses nontransferable. This would in my opinion be a stop gap for a bigger solution because we cannot go ahead and block legitimate business needs for larger entities just because of newcomers like myself. However that ties into my second more realistic approach of what might be accepted but also requires some changes on the administration. How about simply having a split queue system? New members with single LIR goes to the front of the line and gets an nontransferable address. Others will according to their number of existing LIRs or ranges go to the back of the line according to their current ownership where an legitimate need for more ranges constitutes an expected revenue across said ranges and as such the bigger expectancy of acquiring larger ranges via an market otherwise said ranges are not being utilized properly (i understand the existence of non profits and edge cases but not everyone can be 100% satisfied, neither can i with this in the future) Make an buffer that is not possible to be allocated to multi LIRs/multi range holders. I am not an old member enough to have good insight to where a good buffer would be but for arguments sake i would say 100. This means that there is supposed to be 100 /24 ranges available (Could be 20 or 30 or anything RIPE agrees on) and as long as there is, the "Multi holder Queue" would be able to request ranges against motivational uses. There could even be a third queue at say 250 ranges available where all the ranges above that goes to open market against the requirement that they become used within x time and if they are to be resold they have to be resold/rented out at fair pricing. This could be 25,50 or whatever, i don't have the insight yet on how often ranges are allocated to give an accurate number and will not pretend as such either. This would guarantee that the original spirit of the /24's for newcomers idea is retained, while adopting to the wishes of the larger members as well to a degree, I fully understand that there are some really really big entities out there with big needs for IPv4 still and i don't want to block them in any way shape or form because i one day hope to be able to make use of our ranges and services to become on of the really big players, with the benefit of being such a new player that i can already today build IPv6 native and just use IPv4 for the still required things and then hopefully phase out IPv4 and return our ranges down the road. We today have as i mentioned earlier an single IPv4 /24 available for our older WISP/MSP datacenter, It was acquired from an entity called Resilans (If mentioning other entities by name is not allowed i apologize) they also helped us with the process of becoming an LIR and ripe member so we are VERY grateful to them as even tho they did charge for their time, it was a fair price and we would not be here today without them. Entities like them are in my opinion fair and could benefit from the third queue where they did price fairly against us and didnt try to gouge us like other entities that have contacted us after we became members (some asked for outrageous prices for a single /24) They also provide the ability for non members that cannot become members for some reason to acquire IPs for their business, such as it was for us back then. We didn't have any multi-homing ability which we now will with Datacenter 2 (Which is our fiber ISP location) and our L2 link between them. So we didn't even qualify until recently and we also didn't feel we could justify for our then VERY small operations being an LIR and the administration around that, there are others like us out there and for them an resell/second hand renting market of IPv4 is very beneficial We all know IPv4 is a sinking ship and we implement stop gaps such as NAT and then CGNAT to try and prolong its inevitable doom, but until that day comes i hope that my understanding of RIPE so far is accurate where you.. Us all try to make the playing field as equal as possible without hindering each others opportunities. Sorry for the mile long message but this is in my opinion one of several potential ways to do this down the road that might help in some way. I would also like to put out there the idea of presenting the number of ranges in store on the LIR waiting list graph, it would serve two purposes. It would allow small entities like us that when there is a 0 waiting line to have an understanding of how soon there might be a queue again so we can plan our potential entry as an LIR. I actually held off on us being an LIR because we had so much else to prepare and get in place for our new venture, if i would have seen the graph rapidly declining i would have tried to become one sooner and perhaps been able to grab one prior to the member days rather than come in 5 days after the waiting list shot up. The second benefit would also be to drive home the acute situation to everyone and perhaps open up for more understanding for the smaller entities out there that have to rely on this service to get IPv4 other than turning to in some cases heavily overpriced addresses. One last thing before i end this already too long rant. Thank you all so far for not only actually listening to a newcomers rant about our opinion, but also truly showing to us that you really care about our opinion and input. We cant wait to be able to bring back and contribute to this community and hopefully prove our self worthy of the time and consideration shown so far. Very warm regards, Mathias W CEO and Infrastructure Architect - West digital Management AB. On Fri, Dec 10, 2021 at 10:58 AM Sander Steffann wrote: > Hi Mathias, > > > 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.. > > Don't worry, you talk about your frustration quite politely :) And it is > totally justified. This is why I think something needs to be done now. Yes, > it's rearranging deckchairs on the Titanic, but some people are still > trying to survive. > > As a new member, what do you think about these ideas? Would it be good to > make addresses untransferable? Or keep them transferable but ask the NCC to > impose a one-time merger&acquisition fee? Or any other way? What would be > ok for your real internet business but not for address sellers? > > Cheers, > Sander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at albahost.net Sun Dec 12 11:22:22 2021 From: info at albahost.net (Albanian Hosting SH.P.K.) Date: Sun, 12 Dec 2021 11:22:22 +0100 Subject: [address-policy-wg] IPv4 waiting list policy Message-ID: Hello there, it is interesting to see that everyone is shooting to newcomers/new LIRs and nobody is talking about existing one, it is not the issue to prevent transfer resources, the issue is that almost 70% of members that have multiple /20, /21, /22, /24, are renting the IPs. They took from RIPE and renting out at minimal 150 upto 200?/month for a /24 subnet. The same thing happen to us, as a small company that we cannot get more than a /24 subnet we are forced to rent IPs from those who have multiple LIR accounts and alot of IPs for mentioned price. By implementing the non-transfer resources from newcomers/LIRs you will not solve anything, or maybe a less precentage, but you will not stop big boys with alot of resources to rent them with 200?/month (for now, the price will go up) for a /24 subnet. I do agree with Rick Bakker posts. Kind Regards, Mentor L. -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakov?, Kosov?. NIPT/VAT ID: 811442657 T: +386900501502 E: info at albahost.net W*: *wWw.AlbaHost.Net [image: Facebook icon] [image: Twitter icon] [image: Instagram icon] [image: Banner] P?rmbajtja e k?tij emaili ?sht? konfidenciale dhe ka p?r q?llim marr?sin e specifikuar vet?m n? mesazh. Ndalohet rrept?sisht shp?rndarja e ndonj? pjese t? k?tij mesazhi me ndonj? pal? t? tret?, pa p?lqimin me shkrim t? d?rguesit. N?se e keni marr? k?t? mesazh gabimisht, ju lutemi p?rgjigjuni k?tij mesazhi dhe ndiqni me fshirjen e tij, n? m?nyr? q? t? sigurohemi q? nj? gabim i till? t? mos ndodh? n? t? ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Mon Dec 13 01:32:30 2021 From: nick at foobar.org (Nick Hilliard) Date: Mon, 13 Dec 2021 00:32:30 +0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> Message-ID: <95e0dfe9-fd02-8a79-66ae-2ab6f04aa826@foobar.org> Mathias Westerlund wrote on 12/12/2021 07:50: > I realize it is not an easy thing to solve. > I also both feel and understand that something needs to be done due to > the situation at hand. this situation can't be solved: it can only be managed. There's a unresolvable high demand for number resources, and an unresolvable shortage of supply. The challenge is to work out what categories of problems we can live with, and then devise policies to implement that. This is how the current policies came into existence. In regard to creating new policies or updating current ones: - the ultimate aim is accurate registration of resources - there is reluctance on the part of RIRs to deregister previously allocated number resources except in cases of contractual default - due to the high perceived value of ipv4 address resources, reclaiming addresses due to contractual default is likely to slow down in future - the greater the difference between supply and demand, the higher the price on the open market, and the more this will hurt organisations who need ip addresses, and the more demand there will be to change the rules to something else. - "new entrant" companies can be created simply and quickly (i.e. prioritising "new entrants" will create more avenues to abuse the registration system). - increasing the price of registration of addresses solves some problems but creates others - the RIR cannot make a value judgement about whose legitimate need for IP addresses is more important - some people will try hard to cheat the system, and some will succeed - whatever policy is implemented, it needs to be applied fairly and rigorously - the policies and implementations need to be compliant with local and regional laws / regulations The intersection of these constraints rules out many options for creating new policies. Nick > The problem is that many of the solutions i would think of may include > administration overhead, but i guess i will put forward two maybe three > ideas. > > The first and easiest but that will not satisfy everyone is the most > obvious one. > Only allow new members to procure from the waiting list and make the > addresses nontransferable. > > This would in my opinion be a stop gap for a bigger solution because we > cannot go ahead and block legitimate business needs for larger entities > just because of newcomers like myself. > However that ties into my second more realistic approach of what might > be accepted but also requires some changes on the administration. > > How about simply having a split queue system? > New members with single LIR goes to the front of the line and gets an > nontransferable address. > Others will according to their number of existing LIRs or ranges go to > the back of the line according to their current ownership where an > legitimate need for more ranges constitutes an expected revenue across > said ranges and as such the bigger expectancy of acquiring larger ranges > via an market otherwise said ranges are not being utilized properly (i > understand the existence of non profits and edge cases but not everyone > can be 100% satisfied, neither can i with this in the future) > Make an buffer that is not possible to be allocated to multi LIRs/multi > range holders. > I am not an old member enough to have good insight to where a good > buffer would be but for arguments sake i would say 100. > > This means that there is supposed to be 100 /24 ranges available (Could > be 20 or 30 or anything RIPE agrees on) and as long as there is, the > "Multi holder Queue" would be able to request ranges against > motivational uses. > > There could even be a third queue at say 250 ranges available where all > the ranges above that goes to open market against the requirement that > they become used within x time and if they are to be resold they have to > be resold/rented out at fair pricing. This could be 25,50 or whatever, i > don't have the insight yet on how often ranges are allocated to give an > accurate number and will not pretend as such either. > > This would guarantee that the original spirit of the /24's for newcomers > idea is retained, while adopting to the wishes of the larger members as > well to a degree, I fully understand that there are some really really > big entities out there with big needs for IPv4 still and i don't want to > block them in any way shape or form because i one day hope to be able to > make use of our ranges and services to become on of the really big > players, with the benefit of being such a new player that i can already > today build IPv6 native and just use IPv4 for the still required things > and then hopefully phase out IPv4 and return our ranges down the road. > > We today have as i mentioned earlier an single IPv4 /24 available for > our older WISP/MSP datacenter, It was acquired from an entity called > Resilans (If mentioning other entities by name is not allowed i > apologize) they also helped us with the process of becoming an LIR and > ripe member so we are VERY grateful to them as even tho they did charge > for their time, it was a fair price and we would not be here today > without them. > > Entities like them are in my opinion fair and could benefit from the > third queue where they did price fairly against us and didnt try to > gouge us like other entities that have contacted us after we became > members (some asked for outrageous prices for a single /24) > They also provide the ability for non members that cannot become members > for some reason to acquire IPs for their business, such as it was for us > back then. We didn't have any multi-homing ability which we now will > with Datacenter 2 (Which is our fiber ISP location) and our L2 link > between them. So we didn't even qualify until recently and we also > didn't feel we could justify for our then VERY small operations being an > LIR and the administration around that, there are others like us out > there and for them an resell/second hand renting market of IPv4 is very > beneficial > > We all know IPv4 is a sinking ship and we implement stop gaps such as > NAT and then CGNAT to try and prolong its inevitable doom, but until > that day comes i hope that my understanding of RIPE so far is accurate > where you.. Us all try to make the playing field as equal as possible > without hindering each others opportunities. > > Sorry for the mile long message but this is in my opinion one of several > potential ways to do this down the road that might help in some way. > > I would also like to put out there the idea of presenting the number of > ranges in store on the LIR waiting list graph, it would serve two purposes. > > It would allow small entities like us that when there is a 0 waiting > line to have an understanding of how soon there might be a queue again > so we can plan our potential entry as an LIR. I actually held off on us > being an LIR because we had so much else to prepare and get in place for > our new venture, if i would have seen the graph rapidly declining i > would have tried to become one sooner and perhaps been able to grab one > prior to the member days rather than come in 5 days after the waiting > list shot up. > > The second benefit would also be to drive home the acute situation to > everyone and perhaps open up for more understanding for the smaller > entities out there that have to rely on this service to get IPv4 other > than turning to in some cases heavily overpriced addresses. > > One last thing before i end this already too long rant. > Thank you all so far for not only actually listening to a newcomers rant > about our opinion, but also truly showing to us that you really care > about our opinion and input. We cant wait to be able to bring back and > contribute to this community and hopefully prove our self worthy of the > time and consideration shown so far. > > Very warm regards, Mathias W > CEO and Infrastructure Architect - West digital Management AB. > > On Fri, Dec 10, 2021 at 10:58 AM Sander Steffann > wrote: > > Hi Mathias, > > > 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.. > > Don't worry, you talk about your frustration quite politely :)? And > it is totally justified. This is why I think something needs to be > done now. Yes, it's rearranging deckchairs on the Titanic, but some > people are still trying to survive. > > As a new member, what do you think about these ideas? Would it be > good to make addresses untransferable? Or keep them transferable but > ask the NCC to impose a one-time merger&acquisition fee? Or any > other way? What would be ok for your real internet business but not > for address sellers? > > Cheers, > Sander > > > From ripedenis at gmail.com Mon Dec 13 16:31:26 2021 From: ripedenis at gmail.com (denis walker) Date: Mon, 13 Dec 2021 16:31:26 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <95e0dfe9-fd02-8a79-66ae-2ab6f04aa826@foobar.org> References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> <95e0dfe9-fd02-8a79-66ae-2ab6f04aa826@foobar.org> Message-ID: Hi Guys I am doing some analysis on recent allocations using a variety of public data. I have some questions some of you may be able to help me with. -What was the policy in 2019 regarding /22 allocations? Was it a free for all? -When was the waiting list implemented? -when was the allocation size dropped to /24? -The companies/LIRs I have been looking at, I see lots of /22 allocations in 2019 and lots of /24 allocations in 2021, but nothing allocated to them in 2020. What happened last year? Maybe it is a coincidence that these random companies made no applications last year. But given the extent to which they were grabbing address space in 2019 and 2021, it seems odd they did nothing last year. cheers denis co-chair DB-WG On Mon, 13 Dec 2021 at 01:32, Nick Hilliard wrote: > > Mathias Westerlund wrote on 12/12/2021 07:50: > > I realize it is not an easy thing to solve. > > I also both feel and understand that something needs to be done due to > > the situation at hand. > > this situation can't be solved: it can only be managed. There's a > unresolvable high demand for number resources, and an unresolvable > shortage of supply. > > The challenge is to work out what categories of problems we can live > with, and then devise policies to implement that. This is how the > current policies came into existence. > > In regard to creating new policies or updating current ones: > > - the ultimate aim is accurate registration of resources > > - there is reluctance on the part of RIRs to deregister previously > allocated number resources except in cases of contractual default > > - due to the high perceived value of ipv4 address resources, reclaiming > addresses due to contractual default is likely to slow down in future > > - the greater the difference between supply and demand, the higher the > price on the open market, and the more this will hurt organisations who > need ip addresses, and the more demand there will be to change the rules > to something else. > > - "new entrant" companies can be created simply and quickly (i.e. > prioritising "new entrants" will create more avenues to abuse the > registration system). > > - increasing the price of registration of addresses solves some problems > but creates others > > - the RIR cannot make a value judgement about whose legitimate need for > IP addresses is more important > > - some people will try hard to cheat the system, and some will succeed > > - whatever policy is implemented, it needs to be applied fairly and > rigorously > > - the policies and implementations need to be compliant with local and > regional laws / regulations > > The intersection of these constraints rules out many options for > creating new policies. > > Nick > > > > The problem is that many of the solutions i would think of may include > > administration overhead, but i guess i will put forward two maybe three > > ideas. > > > > The first and easiest but that will not satisfy everyone is the most > > obvious one. > > Only allow new members to procure from the waiting list and make the > > addresses nontransferable. > > > > This would in my opinion be a stop gap for a bigger solution because we > > cannot go ahead and block legitimate business needs for larger entities > > just because of newcomers like myself. > > However that ties into my second more realistic approach of what might > > be accepted but also requires some changes on the administration. > > > > How about simply having a split queue system? > > New members with single LIR goes to the front of the line and gets an > > nontransferable address. > > Others will according to their number of existing LIRs or ranges go to > > the back of the line according to their current ownership where an > > legitimate need for more ranges constitutes an expected revenue across > > said ranges and as such the bigger expectancy of acquiring larger ranges > > via an market otherwise said ranges are not being utilized properly (i > > understand the existence of non profits and edge cases but not everyone > > can be 100% satisfied, neither can i with this in the future) > > Make an buffer that is not possible to be allocated to multi LIRs/multi > > range holders. > > I am not an old member enough to have good insight to where a good > > buffer would be but for arguments sake i would say 100. > > > > This means that there is supposed to be 100 /24 ranges available (Could > > be 20 or 30 or anything RIPE agrees on) and as long as there is, the > > "Multi holder Queue" would be able to request ranges against > > motivational uses. > > > > There could even be a third queue at say 250 ranges available where all > > the ranges above that goes to open market against the requirement that > > they become used within x time and if they are to be resold they have to > > be resold/rented out at fair pricing. This could be 25,50 or whatever, i > > don't have the insight yet on how often ranges are allocated to give an > > accurate number and will not pretend as such either. > > > > This would guarantee that the original spirit of the /24's for newcomers > > idea is retained, while adopting to the wishes of the larger members as > > well to a degree, I fully understand that there are some really really > > big entities out there with big needs for IPv4 still and i don't want to > > block them in any way shape or form because i one day hope to be able to > > make use of our ranges and services to become on of the really big > > players, with the benefit of being such a new player that i can already > > today build IPv6 native and just use IPv4 for the still required things > > and then hopefully phase out IPv4 and return our ranges down the road. > > > > We today have as i mentioned earlier an single IPv4 /24 available for > > our older WISP/MSP datacenter, It was acquired from an entity called > > Resilans (If mentioning other entities by name is not allowed i > > apologize) they also helped us with the process of becoming an LIR and > > ripe member so we are VERY grateful to them as even tho they did charge > > for their time, it was a fair price and we would not be here today > > without them. > > > > Entities like them are in my opinion fair and could benefit from the > > third queue where they did price fairly against us and didnt try to > > gouge us like other entities that have contacted us after we became > > members (some asked for outrageous prices for a single /24) > > They also provide the ability for non members that cannot become members > > for some reason to acquire IPs for their business, such as it was for us > > back then. We didn't have any multi-homing ability which we now will > > with Datacenter 2 (Which is our fiber ISP location) and our L2 link > > between them. So we didn't even qualify until recently and we also > > didn't feel we could justify for our then VERY small operations being an > > LIR and the administration around that, there are others like us out > > there and for them an resell/second hand renting market of IPv4 is very > > beneficial > > > > We all know IPv4 is a sinking ship and we implement stop gaps such as > > NAT and then CGNAT to try and prolong its inevitable doom, but until > > that day comes i hope that my understanding of RIPE so far is accurate > > where you.. Us all try to make the playing field as equal as possible > > without hindering each others opportunities. > > > > Sorry for the mile long message but this is in my opinion one of several > > potential ways to do this down the road that might help in some way. > > > > I would also like to put out there the idea of presenting the number of > > ranges in store on the LIR waiting list graph, it would serve two purposes. > > > > It would allow small entities like us that when there is a 0 waiting > > line to have an understanding of how soon there might be a queue again > > so we can plan our potential entry as an LIR. I actually held off on us > > being an LIR because we had so much else to prepare and get in place for > > our new venture, if i would have seen the graph rapidly declining i > > would have tried to become one sooner and perhaps been able to grab one > > prior to the member days rather than come in 5 days after the waiting > > list shot up. > > > > The second benefit would also be to drive home the acute situation to > > everyone and perhaps open up for more understanding for the smaller > > entities out there that have to rely on this service to get IPv4 other > > than turning to in some cases heavily overpriced addresses. > > > > One last thing before i end this already too long rant. > > Thank you all so far for not only actually listening to a newcomers rant > > about our opinion, but also truly showing to us that you really care > > about our opinion and input. We cant wait to be able to bring back and > > contribute to this community and hopefully prove our self worthy of the > > time and consideration shown so far. > > > > Very warm regards, Mathias W > > CEO and Infrastructure Architect - West digital Management AB. > > > > On Fri, Dec 10, 2021 at 10:58 AM Sander Steffann > > wrote: > > > > Hi Mathias, > > > > > 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.. > > > > Don't worry, you talk about your frustration quite politely :) And > > it is totally justified. This is why I think something needs to be > > done now. Yes, it's rearranging deckchairs on the Titanic, but some > > people are still trying to survive. > > > > As a new member, what do you think about these ideas? Would it be > > good to make addresses untransferable? Or keep them transferable but > > ask the NCC to impose a one-time merger&acquisition fee? Or any > > other way? What would be ok for your real internet business but not > > for address sellers? > > > > Cheers, > > Sander > > > > > > > > -- > > To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From info at albahost.net Mon Dec 13 17:17:02 2021 From: info at albahost.net (Albanian Hosting SH.P.K.) Date: Mon, 13 Dec 2021 17:17:02 +0100 Subject: [address-policy-wg] IPv4 waiting list policy Message-ID: Hey Denis Walker, in 2019 until the end of december the last /22 allocation was assigned to the members/Lirs, once the ripe stopped assigning /22, there was not that much interest in 2020 for only a /24 subnet. And no, it was not free! Since in 2021 the price per IP skyrocketed, and ripe announced that they are out of stock, due because of this and due because the price per IP is going to the moon, the LIRs (mostly big boys) with multiple allocations started to apply for more and believe me they are making a good profit from this. For now is 200?/month is the price for /24 subnet to rent out, and it will be higher and higher. Cheers. -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakov?, Kosov?. NIPT/VAT ID: 811442657 T: +386900501502 E: info at albahost.net W*: *wWw.AlbaHost.Net [image: Facebook icon] [image: Twitter icon] [image: Instagram icon] [image: Banner] P?rmbajtja e k?tij emaili ?sht? konfidenciale dhe ka p?r q?llim marr?sin e specifikuar vet?m n? mesazh. Ndalohet rrept?sisht shp?rndarja e ndonj? pjese t? k?tij mesazhi me ndonj? pal? t? tret?, pa p?lqimin me shkrim t? d?rguesit. N?se e keni marr? k?t? mesazh gabimisht, ju lutemi p?rgjigjuni k?tij mesazhi dhe ndiqni me fshirjen e tij, n? m?nyr? q? t? sigurohemi q? nj? gabim i till? t? mos ndodh? n? t? ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.bromwich at stacuity.com Mon Dec 13 17:39:54 2021 From: mike.bromwich at stacuity.com (Mike Bromwich) Date: Mon, 13 Dec 2021 16:39:54 -0000 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: <006001d7f040$0f6bb890$2e4329b0$@mikebromwich.com> Hi, We?re a start-up ? and need a small allocation of IPv4 to connect our platform and to start generating revenue for our business. For us, even the RIPE joining and annual fees are a sizeable cost ? and then having to pay around ?10K for a /24 is a real problem. Unfortunately, we need to connect to the GRX network ? so IPv6 is not an option, and nor is using a suballocation from a third party. We?re on the waiting list ? but seemingly not going anywhere fast. I realize that it?s inevitable that a hot market will emerge for such a precious resource ? but it is disappointing that those new businesses who genuinely need a small allocation for their originally intended use (connectivity) are hindered by those who just speculate with no intention of actually using the addresses. I am new to the scene and so unfortunately don?t have any useful suggestions to make ? but it seems that something has to change since the current dynamic seems abusive. Regards, Mike Bromwich mike.bromwich at stacuity.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathias.westerlund at wdmab.se Mon Dec 13 18:37:52 2021 From: mathias.westerlund at wdmab.se (Mathias Westerlund) Date: Mon, 13 Dec 2021 18:37:52 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <006001d7f040$0f6bb890$2e4329b0$@mikebromwich.com> References: <006001d7f040$0f6bb890$2e4329b0$@mikebromwich.com> Message-ID: Heya, Good (well, not really) to see that we are not the only ones with this experience, As i have stated above we are very small as well and are in need of the allocations for our business, for us too the annual fees and administration regarding them were an absolutely deciding factor in why we held off for so long. However, that doesn't mean I am against the fee. quite the opposite due to what it is used for. Welcome to the gang I guess? However, I was informed that we should be seeing allocations hit us no later than the end of January as things look right now. I can't guarantee that is the case for you. But hopefully it is. Regards, Mathias W. On Mon, Dec 13, 2021 at 5:40 PM Mike Bromwich wrote: > Hi, > > > > We?re a start-up ? and need a small allocation of IPv4 to connect our > platform and to start generating revenue for our business. For us, even the > RIPE joining and annual fees are a sizeable cost ? and then having to pay > around ?10K for a /24 is a real problem. Unfortunately, we need to connect > to the GRX network ? so IPv6 is not an option, and nor is using a > suballocation from a third party. We?re on the waiting list ? but seemingly > not going anywhere fast. > > > > I realize that it?s inevitable that a hot market will emerge for such a > precious resource ? but it is disappointing that those new businesses who > genuinely need a small allocation for their originally intended use > (connectivity) are hindered by those who just speculate with no intention > of actually using the addresses. > > > > I am new to the scene and so unfortunately don?t have any useful > suggestions to make ? but it seems that something has to change since the > current dynamic seems abusive. > > > > Regards, > > > > Mike Bromwich > > mike.bromwich at stacuity.com > -- > > 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: From ripedenis at gmail.com Tue Dec 14 14:20:04 2021 From: ripedenis at gmail.com (denis walker) Date: Tue, 14 Dec 2021 14:20:04 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Hi Guys I have some more questions now as I dig deeper into these allocations. Marco mentioned in his email that the situation is quite fluid because of consolidations, transfers, and opening of new LIR accounts that occur all the time. I have found the transfer information, where can I find details of consolidations? Also is the waiting list published anywhere? I have seen companies with say 25 LIRs where 22 have already received a /24 this year. I would like to know if the other 3 LIRs are on the waiting list and at what position. Now I have some detailed questions about what is meant by consolidation. I will illustrate with an anonymous example. For all my analysis I will not identify any company by name. My intention is to expose behaviour. So we have a parent company ABC Networks BV. They set up 5 child companies. One in 2017 and 4 in early 2019. One of them is XYZ Networks BV. XYZ networks BV opens 12 LIRs. Throughout 2019 each of these LIRs receive a /22 allocation. In December 2019 all these LIRs/allocations moved to the parent company ABC Networks BV and the child company XYZ Networks BV was deregistered according to the Chamber of Commerce. In total the 5 child companies opened 50 LIRs. They each received a /22 throughout 2019 and all these child companies were deregistered in December 2019 with their LIRs/allocations 'transferred' to the parent company. Is this what is meant by consolidation? Not sure what the business case is to register several companies who open several LIRs each to get allocations, then close the companies a few months later and merge all the resources into the parent company...unless it is to try to hide the true number of LIRs the parent company has set up. The timing is also interesting. All of these child companies were merged with the parent company on 2 December 2019, according to the Chamber of Commerce: "Merger deed passed on 02-12-2019. Acquiring legal entity: ABC Networks BV Disappearing legal entities: XYZ Networks BV..." The child companies were then all deregistered on 5 December 2019, according to the Chamber of Commerce: "As of 5-12-2019, the legal entity has been deregistered due to Termination of registration" According to the Transfer Statistics the date of the transfer of the resources was 23 December 2019 from the child company XYZ Networks BV to the parent company ABC Networks BV. The ORGANISATION objects in the RIPE Database were also modified on 23 December 2019 to change the "org-name:" to that of the parent company ABC Networks BV. But the child company XYZ Networks BV did not exist on 23 December 2019. So was this a valid transfer? This applies to all 50 of the allocated resources to these child companies's LIRs. I suspect that when the merger took place on 2 December 2019 the parent company took legal ownership of the assets of the child company, including the LIR accounts with the allocated resources. That means the transfer actually took place on 2 December 2019, not the 23 December 2019 as stated in the Transfer Statistics. That makes the Transfer Statistics wrong. If this is meant to be a legal document that is not good. Something needs to be tightened up here. Maybe it is a chicken & egg situation. The merger has to legally occur and documents supplied to the RIPE NCC before the transfer can be acknowledged. But then the transfer stats should make it clear the transfer actually took place on 2 December when the merger occurred, not the date it was acknowledged by the RIE NCC on 23 December. It is also not clear to me what has actually been transferred/acquired? Is it the allocations or the LIR accounts with the allocations? In the delegated stats there still exists several entries for nl.xyz1, nl.xyz2, etc. These all refer to the legal name of the parent company ABC Networks BV. Does this mean the parent company has taken control (acquired) all 50 of these LIR accounts with their allocations, not just the allocations? Is this still a consolidation? Another general question. When a whole resource is transferred (within RIPE region) it looks like the RIPE NCC deletes and recreates the allocation object in the RIPE Database with 'todays' date as the creation date. But the entry in the delegated stats keeps the original allocation date. Is this how it is meant to be documented? (A good example of why a historical query in the RIPE Database should show the full history.) None of this is explained very well, or at all, in the policies or documentation. It assumes people know a lot more about this registration stuff than a database expert does (but I am learning). If someone can answer these points it may well help some of the new LIRs as well. I am sure there is a steep learning curve here for the newbies. cheers denis co-chair DB-WG On Mon, 13 Dec 2021 at 17:17, Albanian Hosting SH.P.K. via address-policy-wg wrote: > Hey Denis Walker, > > in 2019 until the end of december the last /22 allocation was assigned to > the members/Lirs, once the ripe stopped assigning /22, there was not that > much interest in 2020 for only a /24 subnet. And no, it was not free! Since > in 2021 the price per IP skyrocketed, and ripe announced that they are out > of stock, due because of this and due because the price per IP is going to > the moon, the LIRs (mostly big boys) with multiple allocations started to > apply for more and believe me they are making a good profit from this. For > now is 200?/month is the price for /24 subnet to rent out, and it will be > higher and higher. > > Cheers. > > -- > *Sinqerisht / Sincerely,* > AlbHost [image: Logo] > > Albanian Hosting SH.P.K. > Besim Beka p.n. > 50000 Gjakov?, Kosov?. > NIPT/VAT ID: 811442657 > T: +386900501502 > E: info at albahost.net > > W*: *wWw.AlbaHost.Net [image: Facebook icon] > [image: Twitter icon] > [image: Instagram icon] > > > [image: Banner] > > > P?rmbajtja e k?tij emaili ?sht? konfidenciale dhe ka p?r q?llim marr?sin e > specifikuar vet?m n? mesazh. Ndalohet rrept?sisht shp?rndarja e ndonj? > pjese t? k?tij mesazhi me ndonj? pal? t? tret?, pa p?lqimin me shkrim t? > d?rguesit. N?se e keni marr? k?t? mesazh gabimisht, ju lutemi p?rgjigjuni > k?tij mesazhi dhe ndiqni me fshirjen e tij, n? m?nyr? q? t? sigurohemi q? > nj? gabim i till? t? mos ndodh? n? t? ardhmen. > > The content of this email is confidential and intended for the recipient > specified in message only. It is strictly forbidden to share any part of > this message with any third party, without a written consent of the sender. > If you received this message by mistake, please reply to this message and > follow with its deletion, so that we can ensure such a mistake does not > occur in the future. > > > -- > > 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: From flo at degnet.de Tue Dec 14 14:34:10 2021 From: flo at degnet.de (Florian Fuessl) Date: Tue, 14 Dec 2021 14:34:10 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: <03FBF787-8057-41CE-BDFA-6B0DC36E6565@degnet.de> In order to prevent resource allocation abuse like these examples, RIPE should introduce a significant one time fee for resource transfer(s) due to LIR membership mergers or acquisitions. In case the LIR member being merged or acquired can verify reasonable network activities (not just collecting IPv4 resources for the sake of making profits later), this one time fee will be deductible from the LIR membership fees of the buyer in the upcoming years. So it should not have any effect on reasonable transactions due to mergers or acquisitions but block making profits for IPv4 traders. -Florian > > Hi Guys > > I have some more questions now as I dig deeper into these allocations. Marco mentioned in his email that the situation is quite fluid because of consolidations, transfers, and opening of new LIR accounts that occur all the time. I have found the transfer information, where can I find details of consolidations? Also is the waiting list published anywhere? I have seen companies with say 25 LIRs where 22 have already received a /24 this year. I would like to know if the other 3 LIRs are on the waiting list and at what position. > > Now I have some detailed questions about what is meant by consolidation. I will illustrate with an anonymous example. For all my analysis I will not identify any company by name. My intention is to expose behaviour. > > So we have a parent company ABC Networks BV. They set up 5 child companies. One in 2017 and 4 in early 2019. One of them is XYZ Networks BV. > > XYZ networks BV opens 12 LIRs. Throughout 2019 each of these LIRs receive a /22 allocation. In December 2019 all these LIRs/allocations moved to the parent company ABC Networks BV and the child company XYZ Networks BV was deregistered according to the Chamber of Commerce. > > In total the 5 child companies opened 50 LIRs. They each received a /22 throughout 2019 and all these child companies were deregistered in December 2019 with their LIRs/allocations 'transferred' to the parent company. Is this what is meant by consolidation? Not sure what the business case is to register several companies who open several LIRs each to get allocations, then close the companies a few months later and merge all the resources into the parent company...unless it is to try to hide the true number of LIRs the parent company has set up. > > The timing is also interesting. All of these child companies were merged with the parent company on 2 December 2019, according to the Chamber of Commerce: > "Merger deed passed on 02-12-2019. Acquiring legal entity: ABC Networks BV Disappearing legal entities: XYZ Networks BV..." > The child companies were then all deregistered on 5 December 2019, according to the Chamber of Commerce: > "As of 5-12-2019, the legal entity has been deregistered due to Termination of registration" > > According to the Transfer Statistics the date of the transfer of the resources was 23 December 2019 from the child company XYZ Networks BV to the parent company ABC Networks BV. The ORGANISATION objects in the RIPE Database were also modified on 23 December 2019 to change the "org-name:" to that of the parent company ABC Networks BV. But the child company XYZ Networks BV did not exist on 23 December 2019. So was this a valid transfer? This applies to all 50 of the allocated resources to these child companies's LIRs. > > I suspect that when the merger took place on 2 December 2019 the parent company took legal ownership of the assets of the child company, including the LIR accounts with the allocated resources. That means the transfer actually took place on 2 December 2019, not the 23 December 2019 as stated in the Transfer Statistics. That makes the Transfer Statistics wrong. If this is meant to be a legal document that is not good. Something needs to be tightened up here. Maybe it is a chicken & egg situation. The merger has to legally occur and documents supplied to the RIPE NCC before the transfer can be acknowledged. But then the transfer stats should make it clear the transfer actually took place on 2 December when the merger occurred, not the date it was acknowledged by the RIE NCC on 23 December. > > It is also not clear to me what has actually been transferred/acquired? Is it the allocations or the LIR accounts with the allocations? In the delegated stats there still exists several entries for nl.xyz1, nl.xyz2, etc. These all refer to the legal name of the parent company ABC Networks BV. Does this mean the parent company has taken control (acquired) all 50 of these LIR accounts with their allocations, not just the allocations? Is this still a consolidation? > > Another general question. When a whole resource is transferred (within RIPE region) it looks like the RIPE NCC deletes and recreates the allocation object in the RIPE Database with 'todays' date as the creation date. But the entry in the delegated stats keeps the original allocation date. Is this how it is meant to be documented? (A good example of why a historical query in the RIPE Database should show the full history.) > > None of this is explained very well, or at all, in the policies or documentation. It assumes people know a lot more about this registration stuff than a database expert does (but I am learning). If someone can answer these points it may well help some of the new LIRs as well. I am sure there is a steep learning curve here for the newbies. > > cheers > denis > co-chair DB-WG > From info at albahost.net Tue Dec 14 15:03:05 2021 From: info at albahost.net (Albanian Hosting SH.P.K.) Date: Tue, 14 Dec 2021 15:03:05 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Very interesting! Good catch. And thank you for the information provided, i personally believe that there is no help as because nobody cares at least not the RIPE NCC itself. I do believe that we all are wasting our time here, as long as my small company need a /22 allocation and cannot get it, it's worthless. We are renting them from others in order to survive! On Tue, Dec 14, 2021 at 2:20 PM denis walker wrote: > Hi Guys > > I have some more questions now as I dig deeper into these allocations. > Marco mentioned in his email that the situation is quite fluid because of > consolidations, transfers, and opening of new LIR accounts that occur all > the time. I have found the transfer information, where can I find details > of consolidations? Also is the waiting list published anywhere? I have seen > companies with say 25 LIRs where 22 have already received a /24 this year. > I would like to know if the other 3 LIRs are on the waiting list and at > what position. > > Now I have some detailed questions about what is meant by consolidation. I > will illustrate with an anonymous example. For all my analysis I will not > identify any company by name. My intention is to expose behaviour. > > So we have a parent company ABC Networks BV. They set up 5 child > companies. One in 2017 and 4 in early 2019. One of them is XYZ Networks BV. > > XYZ networks BV opens 12 LIRs. Throughout 2019 each of these LIRs receive > a /22 allocation. In December 2019 all these LIRs/allocations moved to the > parent company ABC Networks BV and the child company XYZ Networks BV was > deregistered according to the Chamber of Commerce. > > In total the 5 child companies opened 50 LIRs. They each received a /22 > throughout 2019 and all these child companies were deregistered in December > 2019 with their LIRs/allocations 'transferred' to the parent company. Is > this what is meant by consolidation? Not sure what the business case is to > register several companies who open several LIRs each to get allocations, > then close the companies a few months later and merge all the resources > into the parent company...unless it is to try to hide the true number of > LIRs the parent company has set up. > > The timing is also interesting. All of these child companies were merged > with the parent company on 2 December 2019, according to the Chamber of > Commerce: > "Merger deed passed on 02-12-2019. Acquiring legal entity: ABC Networks BV > Disappearing legal entities: XYZ Networks BV..." > The child companies were then all deregistered on 5 December 2019, > according to the Chamber of Commerce: > "As of 5-12-2019, the legal entity has been deregistered due to > Termination of registration" > > According to the Transfer Statistics the date of the transfer of the > resources was 23 December 2019 from the child company XYZ Networks BV to > the parent company ABC Networks BV. The ORGANISATION objects in the RIPE > Database were also modified on 23 December 2019 to change the "org-name:" > to that of the parent company ABC Networks BV. But the child company XYZ > Networks BV did not exist on 23 December 2019. So was this a valid > transfer? This applies to all 50 of the allocated resources to these child > companies's LIRs. > > I suspect that when the merger took place on 2 December 2019 the parent > company took legal ownership of the assets of the child company, including > the LIR accounts with the allocated resources. That means the transfer > actually took place on 2 December 2019, not the 23 December 2019 as stated > in the Transfer Statistics. That makes the Transfer Statistics wrong. If > this is meant to be a legal document that is not good. Something needs to > be tightened up here. Maybe it is a chicken & egg situation. The merger has > to legally occur and documents supplied to the RIPE NCC before the transfer > can be acknowledged. But then the transfer stats should make it clear the > transfer actually took place on 2 December when the merger occurred, not > the date it was acknowledged by the RIE NCC on 23 December. > > It is also not clear to me what has actually been transferred/acquired? Is > it the allocations or the LIR accounts with the allocations? In the > delegated stats there still exists several entries for nl.xyz1, nl.xyz2, > etc. These all refer to the legal name of the parent company ABC Networks > BV. Does this mean the parent company has taken control (acquired) all 50 > of these LIR accounts with their allocations, not just the allocations? Is > this still a consolidation? > > Another general question. When a whole resource is transferred (within > RIPE region) it looks like the RIPE NCC deletes and recreates the > allocation object in the RIPE Database with 'todays' date as the creation > date. But the entry in the delegated stats keeps the original allocation > date. Is this how it is meant to be documented? (A good example of why a > historical query in the RIPE Database should show the full history.) > > None of this is explained very well, or at all, in the policies or > documentation. It assumes people know a lot more about this registration > stuff than a database expert does (but I am learning). If someone can > answer these points it may well help some of the new LIRs as well. I am > sure there is a steep learning curve here for the newbies. > > cheers > denis > co-chair DB-WG > > On Mon, 13 Dec 2021 at 17:17, Albanian Hosting SH.P.K. via > address-policy-wg wrote: > >> Hey Denis Walker, >> >> in 2019 until the end of december the last /22 allocation was assigned to >> the members/Lirs, once the ripe stopped assigning /22, there was not that >> much interest in 2020 for only a /24 subnet. And no, it was not free! Since >> in 2021 the price per IP skyrocketed, and ripe announced that they are out >> of stock, due because of this and due because the price per IP is going to >> the moon, the LIRs (mostly big boys) with multiple allocations started to >> apply for more and believe me they are making a good profit from this. For >> now is 200?/month is the price for /24 subnet to rent out, and it will be >> higher and higher. >> >> Cheers. >> >> -- >> *Sinqerisht / Sincerely,* >> AlbHost [image: Logo] >> >> Albanian Hosting SH.P.K. >> Besim Beka p.n. >> 50000 Gjakov?, Kosov?. >> NIPT/VAT ID: 811442657 >> T: +386900501502 >> E: info at albahost.net >> >> W*: *wWw.AlbaHost.Net [image: Facebook icon] >> [image: Twitter icon] >> [image: Instagram icon] >> >> >> [image: Banner] >> >> >> P?rmbajtja e k?tij emaili ?sht? konfidenciale dhe ka p?r q?llim marr?sin >> e specifikuar vet?m n? mesazh. Ndalohet rrept?sisht shp?rndarja e ndonj? >> pjese t? k?tij mesazhi me ndonj? pal? t? tret?, pa p?lqimin me shkrim t? >> d?rguesit. N?se e keni marr? k?t? mesazh gabimisht, ju lutemi p?rgjigjuni >> k?tij mesazhi dhe ndiqni me fshirjen e tij, n? m?nyr? q? t? sigurohemi q? >> nj? gabim i till? t? mos ndodh? n? t? ardhmen. >> >> The content of this email is confidential and intended for the recipient >> specified in message only. It is strictly forbidden to share any part of >> this message with any third party, without a written consent of the sender. >> If you received this message by mistake, please reply to this message and >> follow with its deletion, so that we can ensure such a mistake does not >> occur in the future. >> >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change >> your subscription options, please visit: >> https://mailman.ripe.net/ >> > -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakov?, Kosov?. NIPT/VAT ID: 811442657 T: +386900501502 E: info at albahost.net W*: *wWw.AlbaHost.Net [image: Facebook icon] [image: Twitter icon] [image: Instagram icon] [image: Banner] P?rmbajtja e k?tij emaili ?sht? konfidenciale dhe ka p?r q?llim marr?sin e specifikuar vet?m n? mesazh. Ndalohet rrept?sisht shp?rndarja e ndonj? pjese t? k?tij mesazhi me ndonj? pal? t? tret?, pa p?lqimin me shkrim t? d?rguesit. N?se e keni marr? k?t? mesazh gabimisht, ju lutemi p?rgjigjuni k?tij mesazhi dhe ndiqni me fshirjen e tij, n? m?nyr? q? t? sigurohemi q? nj? gabim i till? t? mos ndodh? n? t? ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adallara at ripe.net Tue Dec 14 17:47:36 2021 From: adallara at ripe.net (Angela Dall'Ara) Date: Tue, 14 Dec 2021 17:47:36 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> <95e0dfe9-fd02-8a79-66ae-2ab6f04aa826@foobar.org> Message-ID: <797f16f7-4156-b4de-fa20-c14b4713d187@ripe.net> Hi Denis, I hope the following answers your questions: Q. What was the policy in 2019 regarding /22 allocations? Was it a free for all? A. From 14 September 2012 to 18 September 2019, the first IPv4 allocation size was limited to a maximum of a single /22 or the equivalent for each LIR, as per ripe-509 which was implemented in January 2011: https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations Through this policy, only LIRs without an IPv4 allocation from the RIPE NCC could request a /22 and they had to provide their intention of making assignments from the allocation. As a side note, the requirement to hold an IPv6 allocation before requesting a /22 IPv4 allocation was removed in March 2015, as per ripe-632: https://www.ripe.net/publications/docs/ripe-632#51 Q. When was the waiting list implemented? Q. When was the allocation size dropped to /24? A. The waiting list was introduced and the IPv4 allocation size reduced from a /22 to /24 on 19 September 2019, as per ripe-725: https://www.ripe.net/publications/docs/ripe-725#51bis Ripe-725 was activated the moment the RIPE NCC could no longer allocate a /22 IPv4 allocation (single range or equivalent) from its IPv4 free pool. Through this policy, the requirement to make assignments from an allocation was removed and only LIRs without an IPv4 allocation could request a /24 IPv4 allocation via the waiting list. Kind regards, Angela -- Angela Dall'Ara RIPE NCC Policy Officer On 13/12/2021 16:31, denis walker wrote: > Hi Guys > > I am doing some analysis on recent allocations using a variety of > public data. I have some questions some of you may be able to help me > with. > > -What was the policy in 2019 regarding /22 allocations? Was it a free for all? > > -When was the waiting list implemented? > > -when was the allocation size dropped to /24? > > -The companies/LIRs I have been looking at, I see lots of /22 > allocations in 2019 and lots of /24 allocations in 2021, but nothing > allocated to them in 2020. What happened last year? Maybe it is a > coincidence that these random companies made no applications last > year. But given the extent to which they were grabbing address space > in 2019 and 2021, it seems odd they did nothing last year. > > cheers > denis > co-chair DB-WG > > On Mon, 13 Dec 2021 at 01:32, Nick Hilliard wrote: >> Mathias Westerlund wrote on 12/12/2021 07:50: >>> I realize it is not an easy thing to solve. >>> I also both feel and understand that something needs to be done due to >>> the situation at hand. >> this situation can't be solved: it can only be managed. There's a >> unresolvable high demand for number resources, and an unresolvable >> shortage of supply. >> >> The challenge is to work out what categories of problems we can live >> with, and then devise policies to implement that. This is how the >> current policies came into existence. >> >> In regard to creating new policies or updating current ones: >> >> - the ultimate aim is accurate registration of resources >> >> - there is reluctance on the part of RIRs to deregister previously >> allocated number resources except in cases of contractual default >> >> - due to the high perceived value of ipv4 address resources, reclaiming >> addresses due to contractual default is likely to slow down in future >> >> - the greater the difference between supply and demand, the higher the >> price on the open market, and the more this will hurt organisations who >> need ip addresses, and the more demand there will be to change the rules >> to something else. >> >> - "new entrant" companies can be created simply and quickly (i.e. >> prioritising "new entrants" will create more avenues to abuse the >> registration system). >> >> - increasing the price of registration of addresses solves some problems >> but creates others >> >> - the RIR cannot make a value judgement about whose legitimate need for >> IP addresses is more important >> >> - some people will try hard to cheat the system, and some will succeed >> >> - whatever policy is implemented, it needs to be applied fairly and >> rigorously >> >> - the policies and implementations need to be compliant with local and >> regional laws / regulations >> >> The intersection of these constraints rules out many options for >> creating new policies. >> >> Nick >> >> >>> The problem is that many of the solutions i would think of may include >>> administration overhead, but i guess i will put forward two maybe three >>> ideas. >>> >>> The first and easiest but that will not satisfy everyone is the most >>> obvious one. >>> Only allow new members to procure from the waiting list and make the >>> addresses nontransferable. >>> >>> This would in my opinion be a stop gap for a bigger solution because we >>> cannot go ahead and block legitimate business needs for larger entities >>> just because of newcomers like myself. >>> However that ties into my second more realistic approach of what might >>> be accepted but also requires some changes on the administration. >>> >>> How about simply having a split queue system? >>> New members with single LIR goes to the front of the line and gets an >>> nontransferable address. >>> Others will according to their number of existing LIRs or ranges go to >>> the back of the line according to their current ownership where an >>> legitimate need for more ranges constitutes an expected revenue across >>> said ranges and as such the bigger expectancy of acquiring larger ranges >>> via an market otherwise said ranges are not being utilized properly (i >>> understand the existence of non profits and edge cases but not everyone >>> can be 100% satisfied, neither can i with this in the future) >>> Make an buffer that is not possible to be allocated to multi LIRs/multi >>> range holders. >>> I am not an old member enough to have good insight to where a good >>> buffer would be but for arguments sake i would say 100. >>> >>> This means that there is supposed to be 100 /24 ranges available (Could >>> be 20 or 30 or anything RIPE agrees on) and as long as there is, the >>> "Multi holder Queue" would be able to request ranges against >>> motivational uses. >>> >>> There could even be a third queue at say 250 ranges available where all >>> the ranges above that goes to open market against the requirement that >>> they become used within x time and if they are to be resold they have to >>> be resold/rented out at fair pricing. This could be 25,50 or whatever, i >>> don't have the insight yet on how often ranges are allocated to give an >>> accurate number and will not pretend as such either. >>> >>> This would guarantee that the original spirit of the /24's for newcomers >>> idea is retained, while adopting to the wishes of the larger members as >>> well to a degree, I fully understand that there are some really really >>> big entities out there with big needs for IPv4 still and i don't want to >>> block them in any way shape or form because i one day hope to be able to >>> make use of our ranges and services to become on of the really big >>> players, with the benefit of being such a new player that i can already >>> today build IPv6 native and just use IPv4 for the still required things >>> and then hopefully phase out IPv4 and return our ranges down the road. >>> >>> We today have as i mentioned earlier an single IPv4 /24 available for >>> our older WISP/MSP datacenter, It was acquired from an entity called >>> Resilans (If mentioning other entities by name is not allowed i >>> apologize) they also helped us with the process of becoming an LIR and >>> ripe member so we are VERY grateful to them as even tho they did charge >>> for their time, it was a fair price and we would not be here today >>> without them. >>> >>> Entities like them are in my opinion fair and could benefit from the >>> third queue where they did price fairly against us and didnt try to >>> gouge us like other entities that have contacted us after we became >>> members (some asked for outrageous prices for a single /24) >>> They also provide the ability for non members that cannot become members >>> for some reason to acquire IPs for their business, such as it was for us >>> back then. We didn't have any multi-homing ability which we now will >>> with Datacenter 2 (Which is our fiber ISP location) and our L2 link >>> between them. So we didn't even qualify until recently and we also >>> didn't feel we could justify for our then VERY small operations being an >>> LIR and the administration around that, there are others like us out >>> there and for them an resell/second hand renting market of IPv4 is very >>> beneficial >>> >>> We all know IPv4 is a sinking ship and we implement stop gaps such as >>> NAT and then CGNAT to try and prolong its inevitable doom, but until >>> that day comes i hope that my understanding of RIPE so far is accurate >>> where you.. Us all try to make the playing field as equal as possible >>> without hindering each others opportunities. >>> >>> Sorry for the mile long message but this is in my opinion one of several >>> potential ways to do this down the road that might help in some way. >>> >>> I would also like to put out there the idea of presenting the number of >>> ranges in store on the LIR waiting list graph, it would serve two purposes. >>> >>> It would allow small entities like us that when there is a 0 waiting >>> line to have an understanding of how soon there might be a queue again >>> so we can plan our potential entry as an LIR. I actually held off on us >>> being an LIR because we had so much else to prepare and get in place for >>> our new venture, if i would have seen the graph rapidly declining i >>> would have tried to become one sooner and perhaps been able to grab one >>> prior to the member days rather than come in 5 days after the waiting >>> list shot up. >>> >>> The second benefit would also be to drive home the acute situation to >>> everyone and perhaps open up for more understanding for the smaller >>> entities out there that have to rely on this service to get IPv4 other >>> than turning to in some cases heavily overpriced addresses. >>> >>> One last thing before i end this already too long rant. >>> Thank you all so far for not only actually listening to a newcomers rant >>> about our opinion, but also truly showing to us that you really care >>> about our opinion and input. We cant wait to be able to bring back and >>> contribute to this community and hopefully prove our self worthy of the >>> time and consideration shown so far. >>> >>> Very warm regards, Mathias W >>> CEO and Infrastructure Architect - West digital Management AB. >>> >>> On Fri, Dec 10, 2021 at 10:58 AM Sander Steffann >> > wrote: >>> >>> Hi Mathias, >>> >>> > 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.. >>> >>> Don't worry, you talk about your frustration quite politely :) And >>> it is totally justified. This is why I think something needs to be >>> done now. Yes, it's rearranging deckchairs on the Titanic, but some >>> people are still trying to survive. >>> >>> As a new member, what do you think about these ideas? Would it be >>> good to make addresses untransferable? Or keep them transferable but >>> ask the NCC to impose a one-time merger&acquisition fee? Or any >>> other way? What would be ok for your real internet business but not >>> for address sellers? >>> >>> Cheers, >>> Sander >>> >>> >>> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From adallara at ripe.net Wed Dec 15 13:22:21 2021 From: adallara at ripe.net (Angela Dall'Ara) Date: Wed, 15 Dec 2021 13:22:21 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: <797f16f7-4156-b4de-fa20-c14b4713d187@ripe.net> References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> <95e0dfe9-fd02-8a79-66ae-2ab6f04aa826@foobar.org> <797f16f7-4156-b4de-fa20-c14b4713d187@ripe.net> Message-ID: Dear colleagues, When reading my answer from yesterday I see I could have been more precise, please see my clarification inline below. On 14/12/2021 17:47, Angela Dall'Ara wrote: > Hi Denis, > > I hope the following answers your questions: > > Q. What was the policy in 2019 regarding /22 allocations? Was it a > free for all? > > A. From 14 September 2012 to 18 September 2019, the first IPv4 > allocation size was limited to a maximum of a single /22 or the > equivalent for each LIR, as per ripe-509 which was implemented in > January 2011: > https://www.ripe.net/publications/docs/ripe-509#----use-of-last----for-pa-allocations > > > Through this policy, only LIRs without an IPv4 allocation from the > RIPE NCC could request a /22 and they had to provide their intention > of making assignments from the allocation. Clarification: Through this policy, only LIRs that did not receive an IPv4 allocation from the RIPE NCC after 14/09/2012 could request a /22 and they had to provide their intention of making assignments from the allocation. > As a side note, the requirement to hold an IPv6 allocation before > requesting a /22 IPv4 allocation was removed in March 2015, as per > ripe-632: > https://www.ripe.net/publications/docs/ripe-632#51 > > > Q. When was the waiting list implemented? > Q. When was the allocation size dropped to /24? > > A. The waiting list was introduced and the IPv4 allocation size > reduced from a /22 to /24 on 19 September 2019, as per ripe-725: > https://www.ripe.net/publications/docs/ripe-725#51bis > > Ripe-725 was activated the moment the RIPE NCC could no longer > allocate a /22 IPv4 allocation (single range or equivalent) from its > IPv4 free pool. > Through this policy, the requirement to make assignments from an > allocation was removed and only LIRs without an IPv4 allocation could > request a /24 IPv4 allocation via the waiting list. Clarification: Through this policy, the LIR's confirmation of the intention to make assignments from an allocation was removed and only LIRs without an IPv4 allocation could request a /24 IPv4 allocation via the waiting list. > > Kind regards, > Angela > -- Angela Dall'Ara RIPE NCC Policy Officer From ripedenis at gmail.com Wed Dec 15 20:00:23 2021 From: ripedenis at gmail.com (denis walker) Date: Wed, 15 Dec 2021 20:00:23 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> <95e0dfe9-fd02-8a79-66ae-2ab6f04aa826@foobar.org> <797f16f7-4156-b4de-fa20-c14b4713d187@ripe.net> Message-ID: Hi Angela I have a question about policy ripe-725. On Wed, 15 Dec 2021 at 13:22, Angela Dall'Ara wrote: > > > Q. When was the waiting list implemented? > > Q. When was the allocation size dropped to /24? > > > > A. The waiting list was introduced and the IPv4 allocation size > > reduced from a /22 to /24 on 19 September 2019, as per ripe-725: > > https://www.ripe.net/publications/docs/ripe-725#51bis Are you saying section 5.1bis of ripe-725 became active as section 5.1 on 19 Sept 2019? This textual change in the policy did not take place in ripe-730, published on 20191010. But waited until ripe-733 published on 20191125. cheers denis From mschmidt at ripe.net Thu Dec 16 16:57:14 2021 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 16 Dec 2021 16:57:14 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Hello Denis, Thank you for your questions. Allow me to answer as many as I can right now. As you indicated, getting the data for some of the requests in your email from 9 December would require quite some time and effort. Considering that Registry Services is currently in the busiest time of the year, I would prefer to first identify if this data would really be beneficial for the ongoing discussion about the IPv4 waiting list policy and potential policy proposal. For example, you asked if some members with 10+ LIR accounts are brokers or are from a certain country. What I can say is that these members are quite diverse. They are located in several countries inside and outside of our service region. Some of these 98 organisations only became members in the last two years, while others opened multiple LIR accounts in the past several years and so received multiple /22 IPv4 allocations under the former "Last /8? policy, and later /24 IPv4 allocations under the current policy. Those members received around 1,100 /22s between September 2012 and November 2019, when the "Last /8" policy was in place. As for your comments about consolidations, I would like to clarify that the RIPE NCC uses this term when a member consolidates some of their LIR accounts into another LIR account. When an LIR receives resources that are restricted by a holding period, those resources must be kept in that LIR account until the holding period has passed. After that 24-month period, these members usually decide to consolidate their LIR accounts, including their resources. If a company were to take over one of its child companies, this would be processed by the RIPE NCC as a merger of two different legal bodies. To provide some more numbers, besides the 98 members that hold 10 or more accounts, we currently have 112 members that hold between 5 and 9 LIR accounts. The maximum amount of /24 allocations that a single member has received under the current policy is 33. So far, no allocations received under the current waiting list policy have been transferred due to the fact that the first such allocation was provided around 24 months ago and almost all allocations are still within their holding period. I hope this answers most of your questions. Kind regards, Marco Schmidt Assistant Manager Registry Services RIPE NCC On 14/12/2021 14:20, denis walker wrote: > Hi Guys > > I have some more questions now as I dig deeper into these allocations. > Marco mentioned in his email that the situation is quite fluid because > of consolidations, transfers, and opening of new LIR accounts that > occur all the time. I have found the transfer information, where can I > find details of consolidations? Also is the waiting list published > anywhere? I have seen companies with say 25 LIRs where 22 have already > received a /24 this year. I would like to know if the other 3 LIRs are > on the waiting list and at what position. > > Now I have some detailed questions about what is meant by > consolidation. I will illustrate with an anonymous example. For all my > analysis I will not identify any company by name. My intention is to > expose behaviour. > > So we have a parent company ABC Networks BV. They set up 5 child > companies. One in 2017 and 4 in early 2019. One of them is XYZ > Networks BV. > > XYZ networks BV opens 12 LIRs. Throughout 2019 each of these LIRs > receive a /22 allocation. In December 2019 all these LIRs/allocations > moved to the parent company ABC Networks BV and the child company XYZ > Networks BV was deregistered according to the Chamber of Commerce. > > In total the 5 child companies opened 50 LIRs. They each received a > /22 throughout 2019 and all these child companies were deregistered in > December 2019 with their LIRs/allocations 'transferred' to the parent > company. Is this what is meant by consolidation? Not sure what the > business case is to register several companies who open several LIRs > each to get allocations, then close the companies a few months later > and merge all the resources into the parent company...unless it is to > try to hide the true number of LIRs the parent company has set up. > > The timing is also interesting. All of these child companies were > merged with the parent company on 2 December 2019, according to the > Chamber of Commerce: > "Merger deed passed on 02-12-2019. Acquiring legal entity: ABC > Networks BV Disappearing legal entities: XYZ Networks BV..." > The child companies were then all deregistered on 5 December 2019, > according to the Chamber of Commerce: > "As of 5-12-2019, the legal entity has been deregistered due to > Termination of registration" > > According to the Transfer Statistics the date of the transfer of the > resources was 23 December 2019 from the child company XYZ Networks BV > to the parent company ABC Networks BV. The ORGANISATION objects in the > RIPE Database were also modified on 23 December 2019 to change the > "org-name:" to that of the parent company ABC Networks BV. But the > child company XYZ Networks BV did not exist on 23 December 2019. So > was this a valid transfer? This applies to all 50 of the allocated > resources to these child companies's LIRs. > > I suspect that when the merger took place on 2 December 2019 the > parent company took legal ownership of the assets of the child > company, including the LIR accounts with the allocated resources. That > means the transfer actually took place on 2 December 2019, not the 23 > December 2019 as stated in the Transfer Statistics. That makes the > Transfer Statistics wrong. If this is meant to be a legal document > that is not good. Something needs to be tightened up here. Maybe it is > a chicken & egg situation. The merger has to legally occur and > documents supplied to the RIPE NCC before the transfer can be > acknowledged. But then the transfer stats should make it clear the > transfer actually took place on 2 December when the merger occurred, > not the date it was acknowledged by the RIE NCC on 23 December. > > It is also not clear to me what has actually been > transferred/acquired? Is it the allocations or the LIR accounts with > the allocations? In the delegated stats there still exists several > entries for nl.xyz1, nl.xyz2, etc. These all refer to the legal name > of the parent company ABC Networks BV. Does this mean the parent > company has taken control (acquired) all 50 of these LIR accounts with > their allocations, not just the allocations? Is this still a > consolidation? > > Another general question. When a whole resource is transferred (within > RIPE region) it looks like the RIPE NCC deletes and recreates the > allocation object in the RIPE Database with 'todays' date as the > creation date. But the entry in the delegated stats keeps the original > allocation date. Is this how it is meant to be documented? (A good > example of why a historical query in the RIPE Database should show the > full history.) > > None of this is explained very well, or at all, in the policies or > documentation. It assumes people know a lot more about this > registration stuff than a database expert does (but I am learning). If > someone can answer these points it may well help some of the new LIRs > as well. I am sure there is a steep learning curve here for the newbies. > > cheers > denis > co-chair DB-WG > > On Mon, 13 Dec 2021 at 17:17, Albanian Hosting SH.P.K. via > address-policy-wg wrote: > > Hey Denis Walker, > > in 2019 until the end of december the last /22 allocation was > assigned to the members/Lirs, once the ripe stopped assigning /22, > there was not that much interest in 2020 for only a /24 subnet. > And no, it was not free! Since in 2021 the price per > IP?skyrocketed, and ripe announced that they are out of stock, due > because of this and due because the price per IP is going to the > moon, the LIRs (mostly big boys) with multiple allocations started > to apply for more and believe me they are making a good profit > from this. For now is 200?/month is the price for /24 subnet to > rent out, and it will be higher and higher. > > Cheers. > > -- > *Sinqerisht / Sincerely,* > AlbHost Logo > Albanian Hosting SH.P.K. > Besim Beka p.n. > 50000 Gjakov?, Kosov?. > NIPT/VAT ID: 811442657 > T: +386900501502 > E: info at albahost.net > W*: *wWw.AlbaHost.Net Facebook icon > Twitter icon > Instagram icon > > Banner > P?rmbajtja e k?tij emaili ?sht? konfidenciale dhe ka p?r q?llim > marr?sin e specifikuar vet?m n? mesazh. Ndalohet rrept?sisht > shp?rndarja e ndonj? pjese t? k?tij mesazhi me ndonj? pal? t? > tret?, pa p?lqimin me shkrim t? d?rguesit. N?se e keni marr? k?t? > mesazh gabimisht, ju lutemi p?rgjigjuni k?tij mesazhi dhe ndiqni > me fshirjen e tij, n? m?nyr? q? t? sigurohemi q? nj? gabim i till? > t? mos ndodh? n? t? ardhmen. > > The content of this email is confidential and intended for the > recipient specified in message only. It is strictly forbidden to > share any part of this message with any third party, without a > written consent of the sender. If you received this message by > mistake, please reply to this message and follow with its > deletion, so that we can ensure such a mistake does not occur in > the future. > > > > > > > -- > > 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: From gert at space.net Thu Dec 16 19:46:18 2021 From: gert at space.net (Gert Doering) Date: Thu, 16 Dec 2021 19:46:18 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Hi, On Tue, Dec 14, 2021 at 03:03:05PM +0100, Albanian Hosting SH.P.K. via address-policy-wg wrote: > Very interesting! Good catch. And thank you for the information provided, i > personally believe that there is no help as because nobody cares at least > not the RIPE NCC itself. I do believe that we all are wasting our time > here, as long as my small company need a /22 allocation and cannot get it, > it's worthless. We are renting them from others in order to survive! If you have read this thread, you might have noticed that people *do* care. It's just not very clear what can be done, at this point in time, which will have a positive effect. There's lots of things that can be done that have negative effects (like, etra bureaucracy, which increases costs, which then leads to complaints about, well, bureaucracy) but have very little effect on the problem statement: networks getting "more than one /24" for the same entity. The problem statement is not as clear cut as it might seem... if a parent company opens a new subsidiary in every european country, which has their own network, budget, CEO... shouldn't they be entitled to have a LIR account and a /24 for each subsidiary? ... and, of course, it's not like we haven't been telling people since 15+ years that IPv4 is going to run out, and they should use IPv6. Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ripe at liopen.fr Thu Dec 16 20:26:46 2021 From: ripe at liopen.fr (Denis Fondras - Liopen) Date: Thu, 16 Dec 2021 20:26:46 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Le Thu, Dec 16, 2021 at 07:46:18PM +0100, Gert Doering a ?crit : > > ... and, of course, it's not like we haven't been telling people since > 15+ years that IPv4 is going to run out, and they should use IPv6. > I find this sentence unfair for all of us who deploy IPv6 but still need to support IPv4 because of big players with millions of IPv4 lagging behind. -- Denis Fondras / Liopen From info at albahost.net Thu Dec 16 20:30:46 2021 From: info at albahost.net (Albanian Hosting SH.P.K.) Date: Thu, 16 Dec 2021 20:30:46 +0100 Subject: [address-policy-wg] Fwd: IPv4 waiting list policy In-Reply-To: References: Message-ID: Hello Gert, appreciate your response, i do believe that you started to care when something is dead now trying to bring to life! On most replies here are only shooting on newcomers/lirs in which no new lir is getting more than a /24, and nobody is talking for those lirs that have multiple resources /16, /17, /20, /21, /22 etc, in which you can clearly see that there is no usage of it by theirself but only leasing/renting them out to those who cannot effort to be LIR and even if they effort it, cannot get more than a /24 allocation. There must be a policy in which it will stop those behaviours of LIRs, if you don't need that much of resource, then return it simple as that, and prevent them from leasing out to people like us. I was working as an IT in one of University in which it has a /16 allocation, and only in use less than a /24, all remaining resource is leased out with monthly fee of course. Of course, if you check every single University in the world has min /15, /16 allocation what for? There are many countries like ours in which IPv6 is nowhere implemented yet, and there are many applications in which is not yet ready for IPv6. So therefore, i hope that this would be considered. Cheers. On Thu, Dec 16, 2021 at 7:46 PM Gert Doering wrote: > Hi, > > On Tue, Dec 14, 2021 at 03:03:05PM +0100, Albanian Hosting SH.P.K. via > address-policy-wg wrote: > > Very interesting! Good catch. And thank you for the information > provided, i > > personally believe that there is no help as because nobody cares at least > > not the RIPE NCC itself. I do believe that we all are wasting our time > > here, as long as my small company need a /22 allocation and cannot get > it, > > it's worthless. We are renting them from others in order to survive! > > If you have read this thread, you might have noticed that people *do* care. > > It's just not very clear what can be done, at this point in time, which > will have a positive effect. > > There's lots of things that can be done that have negative effects > (like, etra bureaucracy, which increases costs, which then leads to > complaints about, well, bureaucracy) but have very little effect on > the problem statement: networks getting "more than one /24" for the > same entity. > > The problem statement is not as clear cut as it might seem... if a parent > company opens a new subsidiary in every european country, which has their > own network, budget, CEO... shouldn't they be entitled to have a LIR > account and a /24 for each subsidiary? > > > ... and, of course, it's not like we haven't been telling people since > 15+ years that IPv4 is going to run out, and they should use IPv6. > > Gert Doering > -- NetMaster > -- > 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 > -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakov?, Kosov?. NIPT/VAT ID: 811442657 T: +386900501502 E: info at albahost.net W*: *wWw.AlbaHost.Net [image: Facebook icon] [image: Twitter icon] [image: Instagram icon] [image: Banner] P?rmbajtja e k?tij emaili ?sht? konfidenciale dhe ka p?r q?llim marr?sin e specifikuar vet?m n? mesazh. Ndalohet rrept?sisht shp?rndarja e ndonj? pjese t? k?tij mesazhi me ndonj? pal? t? tret?, pa p?lqimin me shkrim t? d?rguesit. N?se e keni marr? k?t? mesazh gabimisht, ju lutemi p?rgjigjuni k?tij mesazhi dhe ndiqni me fshirjen e tij, n? m?nyr? q? t? sigurohemi q? nj? gabim i till? t? mos ndodh? n? t? ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. -- *Sinqerisht / Sincerely,* AlbHost [image: Logo] Albanian Hosting SH.P.K. Besim Beka p.n. 50000 Gjakov?, Kosov?. NIPT/VAT ID: 811442657 T: +386900501502 E: info at albahost.net W*: *wWw.AlbaHost.Net [image: Facebook icon] [image: Twitter icon] [image: Instagram icon] [image: Banner] P?rmbajtja e k?tij emaili ?sht? konfidenciale dhe ka p?r q?llim marr?sin e specifikuar vet?m n? mesazh. Ndalohet rrept?sisht shp?rndarja e ndonj? pjese t? k?tij mesazhi me ndonj? pal? t? tret?, pa p?lqimin me shkrim t? d?rguesit. N?se e keni marr? k?t? mesazh gabimisht, ju lutemi p?rgjigjuni k?tij mesazhi dhe ndiqni me fshirjen e tij, n? m?nyr? q? t? sigurohemi q? nj? gabim i till? t? mos ndodh? n? t? ardhmen. The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Dec 16 22:00:29 2021 From: gert at space.net (Gert Doering) Date: Thu, 16 Dec 2021 22:00:29 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Hi, On Thu, Dec 16, 2021 at 08:26:46PM +0100, Denis Fondras - Liopen wrote: > Le Thu, Dec 16, 2021 at 07:46:18PM +0100, Gert Doering a ?crit : > > > > ... and, of course, it's not like we haven't been telling people since > > 15+ years that IPv4 is going to run out, and they should use IPv6. > > > > I find this sentence unfair for all of us who deploy IPv6 but still need to support > IPv4 because of big players with millions of IPv4 lagging behind. Yes, sorry. I did not want to come across as "this is all your own fault", more like "we knew this mess was coming, but failed to handle it in time, as an Industry". But whatever it is, even if some people try hard, we can't create the necessary amount of extra IPv4 space. Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ripedenis at gmail.com Fri Dec 17 07:05:20 2021 From: ripedenis at gmail.com (denis walker) Date: Fri, 17 Dec 2021 07:05:20 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: Message-ID: Hi Marco & APWG colleagues Thanks for the response Marco. Some of my questions below suggest there may be problems with the Transfer Stats and IPv4 Allocation Policy. These questions are not really for the RIPE NCC to answer, except where there are legal implications, but for this WG to consider... On Thu, 16 Dec 2021 at 16:57, Marco Schmidt wrote: > Hello Denis, > > Thank you for your questions. Allow me to answer as many as I can right > now. As you indicated, getting the data for some of the requests in your > email from 9 December would require quite some time and effort. Considering > that Registry Services is currently in the busiest time of the year, I > would prefer to first identify if this data would really be beneficial for > the ongoing discussion about the IPv4 waiting list policy and potential > policy proposal. > It was only for background information and isn't likely to change the discussion very much. So if you are very busy don't worry about those numbers. My own analysis is likely to be far more explosive. I am still working on the details... > As for your comments about consolidations, I would like to clarify that > the RIPE NCC uses this term when a member consolidates some of their LIR > accounts into another LIR account. When an LIR receives resources that are > restricted by a holding period, those resources must be kept in that LIR > account until the holding period has passed. After that 24-month period, > these members usually decide to consolidate their LIR accounts, including > their resources. If a company were to take over one of its child companies, > this would be processed by the RIPE NCC as a merger of two different legal > bodies. > So in a merger/acquisition two legal entities, each with one LIR account, becomes one legal entity with two LIR accounts. A consolidation is when one legal entity has two LIR accounts and closes one of those LIR accounts, transfering it's resources to the remaining LIR account. Is that correct? When a legal entity opens two LIR accounts does the legal entity become two legally distinct RIPE NCC members? With a consolidation, is the 'movement' of a resource from the closed LIR to another LIR operated by the same legal entity considered as a transfer? According to section 2.0 of the Transfer Policy the movement of an allocated resource from one RIPE NCC member to another RIPE NCC member is a transfer. So it looks to me that a consolidation IS a transfer and therefore SHOULD be documented in the Transfer Stats? But I don't see any transfers listed as CONSOLIDATION. Why not? In the IPv4 Allocation Policy (ripe-733), section '3.0 Goals of the Internet Registry System', point 3 says: "Fairness: Public IPv4 address space must be fairly distributed to the End Users operating networks." Given the controversy over companies setting up multiple LIRs to (un)fairly acquire the last bits of IPv4 addresses available through the RIPE NCC being discussed in this thread, in the interests of fairness, as well as openness and transparency, should consolidation 'transfers' be included in the Transfer Stats? With the current /24 allocation policy there is a condition that these allocations cannot be transferred for at least 24 months. Are there any conditions/expectations on who can use this address space or who can administratively and technically control these addresses? Is it acceptable that within these 24 months, a separate legal entity takes over both administrative and technical control of this allocated address space and manages the assignment of it? So the legal entity that received the allocation is just a 'shell' that exists only to satisfy the 24 month no transfer condition. Now I want to ask a very specific legal question. In the Transfer Policy, section '2.1 Transfer Requirements' says: "The original resource holder remains responsible for an Internet number resource until the transfer to the receiving party is completed." So in the example I gave earlier, Company ABC acquired company XYZ (and presumably all it's assets including the LIR it operated) on 2 December. According to the Chamber of Commerce, company XYZ was deregistered on 5 December. So it no longer existed as a legal entity after 5 December. The Transfer Stats state the transfer of the resources from XYZ to ABC occured on 23 December. According to the Transfer Policy section '4.0 Transfer Statistics' says the published date is "The date each resource was transferred". So who was legally responsible for those IP resources between 5 and 23 December? cheers denis co-chair DB-WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From taihen at taihen.org Sat Dec 18 18:10:23 2021 From: taihen at taihen.org (AJ Wolski) Date: Sat, 18 Dec 2021 18:10:23 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <388BD0A6-822C-45D0-94B4-FE22EC6C4DCA@bais.name> Message-ID: On Tue, Dec 7, 2021 at 3:56 PM Gert Doering wrote: > > Hi, > > On Tue, Dec 07, 2021 at 02:29:15PM +0000, Erik Bais wrote: > > As WG chairs we would like to see the position of the WG on the topic and what could be seen as a possible solution. > > As a member of the WG, I do share the sentiment that the intent of the > "IPv4 runout" policies have been "ensure that late comers to the game > can have a bit of IPv4 space, to number their IPv6 translators", and > not "grab some space for free, and sell it for more money elsewhere". > > I do not think this can be fixed on the AGM level ("one legal entity > can only have one LIR account") - we've been there, in the rush to /22s, > and all it does it "make people hide behind shell companies", so in > the end, the address space goes out anyway, but registry quality suffers. > > Trying to make the NCC require even more paperwork isn't going to stop > those that want to game the system, but will impact everyone else by > making the NCC more annoying to deal with. > > > My suggestion would be along the lines what was proposed on the APWG > meeting already - earmark these /24s as non-transferrable, ever. I would definitely support that, but... > Consequences: > > - there is no more financial incentive to "get one cheap, sell it expensive" > > - if you need space to run your business, this is exactly what it is > there for - you can still sell your business (with the /24), you > just need to keep the LIR account. But that's as with other > business assets. > > - if you want to merge multiple LIR accounts, all having their own > /24 - then you need to keep around these accounts, or return some > of the /24s. > - corrolary: if you use these /24s to number your IPv6 translators, > then renumbering this translator into "your other /24" is actually > not very hard. > - corrolary2: If you use the /24s to directly number your customers, > you missed the boat already (wearing my RIPE unicorn t-shirt today). If the goal of the WG is to stop some small number of LIRs abusing the system, make it non-transferrable, but really never, return to the pool. Any "if" will just change the game for those who abuse the system. Hardline only works if we make an assumption that being an LIR is more expensive than "renting" 256 v4 addresses on the market. I don't know how long this will hold on. As it was mentioned already at APWG, I think ARIN approach is more elegant, 5 years is a reasonable number these days. This could be revised to further extend the hold time if needed, rather than the membership fee. Yes, abuse will go on, but less interesting short term and at least with the prospect of proper registration. v6 stats are depressing, v4 is not going away, we are just inflating the prices and further skewing the DB accuracy. AJ Wolski From adallara at ripe.net Mon Dec 20 12:17:36 2021 From: adallara at ripe.net (Angela Dall'Ara) Date: Mon, 20 Dec 2021 12:17:36 +0100 Subject: [address-policy-wg] IPv4 waiting list policy In-Reply-To: References: <20211208151449.GA16632@moon> <9baaf849-30b6-6a1d-17ec-fcf4c6ab9b0e@foobar.org> <0A3FA9B3-0FD3-49C5-87CC-96B853EED3E7@degnet.de> <6BC016DB-CF04-4982-B8D3-733337338DFC@steffann.nl> <95e0dfe9-fd02-8a79-66ae-2ab6f04aa826@foobar.org> <797f16f7-4156-b4de-fa20-c14b4713d187@ripe.net> Message-ID: Hi Denis, ripe-725 has been published on 30 July 2019, following up on the acceptance of policy proposal 2019-02, "IPv4 Waiting List Implementation?, https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-July/012987.html and it has been implemented on 19 September 2019. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-September/013024.html This version stated - in section "5.1 Allocations made by the RIPE NCC to LIRs": "Once an equivalent of a /22 can no longer be allocated, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-serve waiting list. At that point in time the contents of section 5.1 of this policy document will be automatically replaced with the contents of section 5.1bis and section 5.1bis will be deleted from this policy document." - in section "5.2 Unforeseen circumstances": "A /16 will be held in reserve for some future uses, as yet unforeseen. . . . In the event that this /16 remains unused at the time the remaining addresses covered by this policy have been distributed, it returns to the pool to be distributed as per section 5.1, and this section is to be automatically deleted from the policy document." ripe-730 has been published on 10 October 2019, following up on the acceptance of policy proposal 2019-05, "Revised IPv4 assignment policy for IXPs". https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-October/013068.html ripe-733 has been published on 25 November 2019, following up on the automatic updates stated in ripe-725 (see above), as a result of the depletion of the RIPE NCC free IPv4 pool. https://www.ripe.net/ripe/mail/archives/address-policy-wg/2019-November/013114.html Kind regards, Angela -- Angela Dall'Ara RIPE NCC Policy Officer On 15/12/2021 20:00, denis walker wrote: > Hi Angela > > I have a question about policy ripe-725. > > On Wed, 15 Dec 2021 at 13:22, Angela Dall'Ara wrote: >>> Q. When was the waiting list implemented? >>> Q. When was the allocation size dropped to /24? >>> >>> A. The waiting list was introduced and the IPv4 allocation size >>> reduced from a /22 to /24 on 19 September 2019, as per ripe-725: >>> https://www.ripe.net/publications/docs/ripe-725#51bis > Are you saying section 5.1bis of ripe-725 became active as section 5.1 > on 19 Sept 2019? This textual change in the policy did not take place > in ripe-730, published on 20191010. But waited until ripe-733 > published on 20191125. > > cheers > denis From ripedenis at gmail.com Wed Dec 22 16:01:04 2021 From: ripedenis at gmail.com (denis walker) Date: Wed, 22 Dec 2021 16:01:04 +0100 Subject: [address-policy-wg] ripe-682 Transfer Policy Problems Message-ID: Colleagues The Transfer Policy ripe-682 is so vague you can drive a train through the holes in it. I have some questions that I hope someone can answer before Christmas as I would like to propose an amendment to this policy in the new year. "Any legitimate resource holder is allowed to transfer" What does 'legitimate' mean in this context? It is not defined in this policy document. It is no use referring to a dictionary or even some other policy document. It needs to be defined in this policy. If it has no specific meaning in the context of this policy, then the word should be removed. My understanding of a 'policy document' is that it is self contained and consistent. None of the terms: -RIPE NCC Member -LIR -Resource holder are defined anywhere in the Transfer Policy or ripe-733, IPv4 Allocation... A policy may be dependent on another policy being in place. You cannot transfer a resource unless it has been allocated. You cannot allocate a resource unless there is a RIPE NCC Member and an LIR. But you should not have to backtrack through a whole sequence of documents to find out what a term in this policy means. This policy can only work if people understand 'commonly accepted' definitions of these terms. But that is open to interpretation and mis-understanding. That could make legal enforcement of, for example, restrictions more difficult to apply. [As a side issue I have just quickly read through a whole series of documents and forms on becoming a RIPE NCC Member and getting resources. In every document/form I found: -Legal errors -English grammar errors -Procedural errors -Webpage errors The whole process is a complete mess and needs a serious Legal/Comms review.] I found the definition of a Member in one document but nowhere have I found any definition of LIR. These terms are so fundamental to all these policies, to not define them leaves a massive hole in their meaning and authority. These terms seem to be so interchangeable from one paragraph to the next. In some places the wrong term is used. ripe-733 says allocations are made to LIRs ripe-682 says allocations are transferred to members ripe-682 says transfer restrictions apply to resource holders Then we have this document https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers which talks about 'hodership', another term not defined. Then we have this document https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region that conflicts with the Transfer Policy. It also refers to Members as organisations, again without any actual definition. The above document says: "Exception: For transfers between multiple LIR accounts belonging to the same organisation, also referred to as consolidations, the 24 months restriction will only apply once after the resources were received from the RIPE NCC or from another organisation." This is NOT what the Transfer Policy says. The policy makes no mention anywhere of consolidation. The only definition we have of a transfer in any POLICY is this one line: "Allocated resources may only be transferred to another RIPE NCC member." This does not even make sense. A Member cannot 'hold' a resource. Resources are held by Member LIRs. So if a resource is transferred to a Member with 5 LIRs, which one receives it? Does it matter? Is it whichever LIR the Member writes on the transfer request form? Now a consolidation is not a transfer. In the policy a transfer is defined as moving a resource to 'another Member'. So consolidating a resource by moving it from one LIR to another LIR of the same Member is by policy definition, not a transfer. So consolidation is not subject to Transfer Restrictions because it is not a transfer. So all the shell companies that have been set up this year to hoover up the last /24s can now be merged with their parent company and then all the /24s can be consolidated into one LIR. The other LIRs can then be closed. Nothing in this policy document says a /24 allocation must remain for 24 months with the LIR that it was allocated to. It says it cannot be transferred, but mergers are allowed and consolidation is not a transfer. This is even confirmed in a procedural document ripe-758, Transfer of Internet Number Resources... (which doesn't appear to be policy) "Internet number resources that are subject to transfer restrictions imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that are transferred due to a change in a member's business structure, must either remain registered with the original LIR account or be registered with a new LIR account." So merging a shell company with 20 LIRs, each with a /24, with the parent company with a single LIR, allows those 20 /24s to be registered with the single LIR of the parent company and closure of the 20 LIRs. Also ripe-758 introduces yet another term, parties, without any definition or clarity. This whole transfer process is totally confused with contradictory, inconsistent and poorly written documents and policies. cheers denis co-chair DB-WG From arash_mpc at parsun.com Thu Dec 23 03:26:23 2021 From: arash_mpc at parsun.com (Arash Naderpour) Date: Thu, 23 Dec 2021 13:26:23 +1100 Subject: [address-policy-wg] ripe-682 Transfer Policy Problems In-Reply-To: References: Message-ID: There is a catch, 20 LIRs cannot be merged into a single LIR of the new parent company, unless it has passed 2years from the /24 allocation date. So after the merge, the new parent company still has to pay for 20 LIRs till the time /24 can be transferred, Regards, Arash >>So merging a shell company with 20 LIRs, each with a /24, with the parent company with a single LIR, allows those 20 /24s to be registered with the single LIR of the parent company and closure of the 20 LIRs. On Thu, Dec 23, 2021 at 2:01 AM denis walker wrote: > Colleagues > > The Transfer Policy ripe-682 is so vague you can drive a train through > the holes in it. I have some questions that I hope someone can answer > before Christmas as I would like to propose an amendment to this > policy in the new year. > > "Any legitimate resource holder is allowed to transfer" > What does 'legitimate' mean in this context? It is not defined in this > policy document. It is no use referring to a dictionary or even some > other policy document. It needs to be defined in this policy. If it > has no specific meaning in the context of this policy, then the word > should be removed. > > My understanding of a 'policy document' is that it is self contained > and consistent. None of the terms: > -RIPE NCC Member > -LIR > -Resource holder > are defined anywhere in the Transfer Policy or ripe-733, IPv4 > Allocation... A policy may be dependent on another policy being in > place. You cannot transfer a resource unless it has been allocated. > You cannot allocate a resource unless there is a RIPE NCC Member and > an LIR. But you should not have to backtrack through a whole sequence > of documents to find out what a term in this policy means. This policy > can only work if people understand 'commonly accepted' definitions of > these terms. But that is open to interpretation and mis-understanding. > That could make legal enforcement of, for example, restrictions more > difficult to apply. > > [As a side issue I have just quickly read through a whole series of > documents and forms on becoming a RIPE NCC Member and getting > resources. In every document/form I found: > -Legal errors > -English grammar errors > -Procedural errors > -Webpage errors > The whole process is a complete mess and needs a serious Legal/Comms > review.] > > I found the definition of a Member in one document but nowhere have I > found any definition of LIR. These terms are so fundamental to all > these policies, to not define them leaves a massive hole in their > meaning and authority. These terms seem to be so interchangeable from > one paragraph to the next. In some places the wrong term is used. > > ripe-733 says allocations are made to LIRs > ripe-682 says allocations are transferred to members > ripe-682 says transfer restrictions apply to resource holders > > Then we have this document > > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers > which talks about 'hodership', another term not defined. > > Then we have this document > > https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region > that conflicts with the Transfer Policy. > It also refers to Members as organisations, again without any actual > definition. > > The above document says: > "Exception: For transfers between multiple LIR accounts belonging to > the same organisation, also referred to as consolidations, the 24 > months restriction will only apply once after the resources were > received from the RIPE NCC or from another organisation." > > This is NOT what the Transfer Policy says. The policy makes no mention > anywhere of consolidation. The only definition we have of a transfer > in any POLICY is this one line: > "Allocated resources may only be transferred to another RIPE NCC member." > This does not even make sense. A Member cannot 'hold' a resource. > Resources are held by Member LIRs. So if a resource is transferred to > a Member with 5 LIRs, which one receives it? Does it matter? Is it > whichever LIR the Member writes on the transfer request form? > > Now a consolidation is not a transfer. In the policy a transfer is > defined as moving a resource to 'another Member'. So consolidating a > resource by moving it from one LIR to another LIR of the same Member > is by policy definition, not a transfer. So consolidation is not > subject to Transfer Restrictions because it is not a transfer. > > So all the shell companies that have been set up this year to hoover > up the last /24s can now be merged with their parent company and then > all the /24s can be consolidated into one LIR. The other LIRs can then > be closed. Nothing in this policy document says a /24 allocation must > remain for 24 months with the LIR that it was allocated to. It says it > cannot be transferred, but mergers are allowed and consolidation is > not a transfer. > > This is even confirmed in a procedural document ripe-758, Transfer of > Internet Number Resources... (which doesn't appear to be policy) > "Internet number resources that are subject to transfer restrictions > imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that > are transferred due to a change in a member's business structure, must > either remain registered with the original LIR account or be > registered with a new LIR account." > > So merging a shell company with 20 LIRs, each with a /24, with the > parent company with a single LIR, allows those 20 /24s to be > registered with the single LIR of the parent company and closure of > the 20 LIRs. > > Also ripe-758 introduces yet another term, parties, without any > definition or clarity. > > This whole transfer process is totally confused with contradictory, > inconsistent and poorly written documents and policies. > > cheers > denis > co-chair DB-WG > > -- > > 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: From mathias.westerlund at wdmab.se Thu Dec 23 09:22:08 2021 From: mathias.westerlund at wdmab.se (Mathias Westerlund) Date: Thu, 23 Dec 2021 09:22:08 +0100 Subject: [address-policy-wg] ripe-682 Transfer Policy Problems In-Reply-To: References: Message-ID: The member cost is however easily eaten by the income of renting a single /24 in many countries at the moment. So it is barely an hindrance at all and especially not a hindrance for an org betting on the finite nature of ipv4 pushing prices in 2-5 years to crazy levels. On Thu, Dec 23, 2021, 03:27 Arash Naderpour wrote: > There is a catch, > 20 LIRs cannot be merged into a single LIR of the new parent company, > unless it has passed 2years from the /24 allocation date. > So after the merge, the new parent company still has to pay for 20 LIRs > till the time /24 can be transferred, > > Regards, > > Arash > > >>So merging a shell company with 20 LIRs, each with a /24, with the > parent company with a single LIR, allows those 20 /24s to be > registered with the single LIR of the parent company and closure of > the 20 LIRs. > > > > On Thu, Dec 23, 2021 at 2:01 AM denis walker wrote: > >> Colleagues >> >> The Transfer Policy ripe-682 is so vague you can drive a train through >> the holes in it. I have some questions that I hope someone can answer >> before Christmas as I would like to propose an amendment to this >> policy in the new year. >> >> "Any legitimate resource holder is allowed to transfer" >> What does 'legitimate' mean in this context? It is not defined in this >> policy document. It is no use referring to a dictionary or even some >> other policy document. It needs to be defined in this policy. If it >> has no specific meaning in the context of this policy, then the word >> should be removed. >> >> My understanding of a 'policy document' is that it is self contained >> and consistent. None of the terms: >> -RIPE NCC Member >> -LIR >> -Resource holder >> are defined anywhere in the Transfer Policy or ripe-733, IPv4 >> Allocation... A policy may be dependent on another policy being in >> place. You cannot transfer a resource unless it has been allocated. >> You cannot allocate a resource unless there is a RIPE NCC Member and >> an LIR. But you should not have to backtrack through a whole sequence >> of documents to find out what a term in this policy means. This policy >> can only work if people understand 'commonly accepted' definitions of >> these terms. But that is open to interpretation and mis-understanding. >> That could make legal enforcement of, for example, restrictions more >> difficult to apply. >> >> [As a side issue I have just quickly read through a whole series of >> documents and forms on becoming a RIPE NCC Member and getting >> resources. In every document/form I found: >> -Legal errors >> -English grammar errors >> -Procedural errors >> -Webpage errors >> The whole process is a complete mess and needs a serious Legal/Comms >> review.] >> >> I found the definition of a Member in one document but nowhere have I >> found any definition of LIR. These terms are so fundamental to all >> these policies, to not define them leaves a massive hole in their >> meaning and authority. These terms seem to be so interchangeable from >> one paragraph to the next. In some places the wrong term is used. >> >> ripe-733 says allocations are made to LIRs >> ripe-682 says allocations are transferred to members >> ripe-682 says transfer restrictions apply to resource holders >> >> Then we have this document >> >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers >> which talks about 'hodership', another term not defined. >> >> Then we have this document >> >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region >> that conflicts with the Transfer Policy. >> It also refers to Members as organisations, again without any actual >> definition. >> >> The above document says: >> "Exception: For transfers between multiple LIR accounts belonging to >> the same organisation, also referred to as consolidations, the 24 >> months restriction will only apply once after the resources were >> received from the RIPE NCC or from another organisation." >> >> This is NOT what the Transfer Policy says. The policy makes no mention >> anywhere of consolidation. The only definition we have of a transfer >> in any POLICY is this one line: >> "Allocated resources may only be transferred to another RIPE NCC member." >> This does not even make sense. A Member cannot 'hold' a resource. >> Resources are held by Member LIRs. So if a resource is transferred to >> a Member with 5 LIRs, which one receives it? Does it matter? Is it >> whichever LIR the Member writes on the transfer request form? >> >> Now a consolidation is not a transfer. In the policy a transfer is >> defined as moving a resource to 'another Member'. So consolidating a >> resource by moving it from one LIR to another LIR of the same Member >> is by policy definition, not a transfer. So consolidation is not >> subject to Transfer Restrictions because it is not a transfer. >> >> So all the shell companies that have been set up this year to hoover >> up the last /24s can now be merged with their parent company and then >> all the /24s can be consolidated into one LIR. The other LIRs can then >> be closed. Nothing in this policy document says a /24 allocation must >> remain for 24 months with the LIR that it was allocated to. It says it >> cannot be transferred, but mergers are allowed and consolidation is >> not a transfer. >> >> This is even confirmed in a procedural document ripe-758, Transfer of >> Internet Number Resources... (which doesn't appear to be policy) >> "Internet number resources that are subject to transfer restrictions >> imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that >> are transferred due to a change in a member's business structure, must >> either remain registered with the original LIR account or be >> registered with a new LIR account." >> >> So merging a shell company with 20 LIRs, each with a /24, with the >> parent company with a single LIR, allows those 20 /24s to be >> registered with the single LIR of the parent company and closure of >> the 20 LIRs. >> >> Also ripe-758 introduces yet another term, parties, without any >> definition or clarity. >> >> This whole transfer process is totally confused with contradictory, >> inconsistent and poorly written documents and policies. >> >> cheers >> denis >> co-chair DB-WG >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change >> your subscription options, please visit: >> https://mailman.ripe.net/ >> > -- > > 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: From ripedenis at gmail.com Thu Dec 23 20:00:42 2021 From: ripedenis at gmail.com (denis walker) Date: Thu, 23 Dec 2021 20:00:42 +0100 Subject: [address-policy-wg] ripe-682 Transfer Policy Problems In-Reply-To: References: Message-ID: Hi Arash On Thu, 23 Dec 2021 at 03:26, Arash Naderpour wrote: > > There is a catch, > 20 LIRs cannot be merged into a single LIR of the new parent company, unless it has passed 2years from the /24 allocation date. > So after the merge, the new parent company still has to pay for 20 LIRs till the time /24 can be transferred, No, that's one of the points I am making. There is a huge difference between the 'intent' of policies and the actual wording. Consolidation is not mentioned in any policy, only procedural documents of the RIPE NCC. Consolidation is therefore neither allowed nor disallowed by policy. The 24 month restriction is on 'transfers'. The policy defines a transfer as moving resources to 'another member'. So there is no time constraint on consolidation....according to policy. cheers denis co-chair DB-WG > > Regards, > > Arash > > >>So merging a shell company with 20 LIRs, each with a /24, with the > parent company with a single LIR, allows those 20 /24s to be > registered with the single LIR of the parent company and closure of > the 20 LIRs. > > > > On Thu, Dec 23, 2021 at 2:01 AM denis walker wrote: >> >> Colleagues >> >> The Transfer Policy ripe-682 is so vague you can drive a train through >> the holes in it. I have some questions that I hope someone can answer >> before Christmas as I would like to propose an amendment to this >> policy in the new year. >> >> "Any legitimate resource holder is allowed to transfer" >> What does 'legitimate' mean in this context? It is not defined in this >> policy document. It is no use referring to a dictionary or even some >> other policy document. It needs to be defined in this policy. If it >> has no specific meaning in the context of this policy, then the word >> should be removed. >> >> My understanding of a 'policy document' is that it is self contained >> and consistent. None of the terms: >> -RIPE NCC Member >> -LIR >> -Resource holder >> are defined anywhere in the Transfer Policy or ripe-733, IPv4 >> Allocation... A policy may be dependent on another policy being in >> place. You cannot transfer a resource unless it has been allocated. >> You cannot allocate a resource unless there is a RIPE NCC Member and >> an LIR. But you should not have to backtrack through a whole sequence >> of documents to find out what a term in this policy means. This policy >> can only work if people understand 'commonly accepted' definitions of >> these terms. But that is open to interpretation and mis-understanding. >> That could make legal enforcement of, for example, restrictions more >> difficult to apply. >> >> [As a side issue I have just quickly read through a whole series of >> documents and forms on becoming a RIPE NCC Member and getting >> resources. In every document/form I found: >> -Legal errors >> -English grammar errors >> -Procedural errors >> -Webpage errors >> The whole process is a complete mess and needs a serious Legal/Comms review.] >> >> I found the definition of a Member in one document but nowhere have I >> found any definition of LIR. These terms are so fundamental to all >> these policies, to not define them leaves a massive hole in their >> meaning and authority. These terms seem to be so interchangeable from >> one paragraph to the next. In some places the wrong term is used. >> >> ripe-733 says allocations are made to LIRs >> ripe-682 says allocations are transferred to members >> ripe-682 says transfer restrictions apply to resource holders >> >> Then we have this document >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers >> which talks about 'hodership', another term not defined. >> >> Then we have this document >> https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region >> that conflicts with the Transfer Policy. >> It also refers to Members as organisations, again without any actual definition. >> >> The above document says: >> "Exception: For transfers between multiple LIR accounts belonging to >> the same organisation, also referred to as consolidations, the 24 >> months restriction will only apply once after the resources were >> received from the RIPE NCC or from another organisation." >> >> This is NOT what the Transfer Policy says. The policy makes no mention >> anywhere of consolidation. The only definition we have of a transfer >> in any POLICY is this one line: >> "Allocated resources may only be transferred to another RIPE NCC member." >> This does not even make sense. A Member cannot 'hold' a resource. >> Resources are held by Member LIRs. So if a resource is transferred to >> a Member with 5 LIRs, which one receives it? Does it matter? Is it >> whichever LIR the Member writes on the transfer request form? >> >> Now a consolidation is not a transfer. In the policy a transfer is >> defined as moving a resource to 'another Member'. So consolidating a >> resource by moving it from one LIR to another LIR of the same Member >> is by policy definition, not a transfer. So consolidation is not >> subject to Transfer Restrictions because it is not a transfer. >> >> So all the shell companies that have been set up this year to hoover >> up the last /24s can now be merged with their parent company and then >> all the /24s can be consolidated into one LIR. The other LIRs can then >> be closed. Nothing in this policy document says a /24 allocation must >> remain for 24 months with the LIR that it was allocated to. It says it >> cannot be transferred, but mergers are allowed and consolidation is >> not a transfer. >> >> This is even confirmed in a procedural document ripe-758, Transfer of >> Internet Number Resources... (which doesn't appear to be policy) >> "Internet number resources that are subject to transfer restrictions >> imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that >> are transferred due to a change in a member's business structure, must >> either remain registered with the original LIR account or be >> registered with a new LIR account." >> >> So merging a shell company with 20 LIRs, each with a /24, with the >> parent company with a single LIR, allows those 20 /24s to be >> registered with the single LIR of the parent company and closure of >> the 20 LIRs. >> >> Also ripe-758 introduces yet another term, parties, without any >> definition or clarity. >> >> This whole transfer process is totally confused with contradictory, >> inconsistent and poorly written documents and policies. >> >> cheers >> denis >> co-chair DB-WG >> >> -- >> >> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/ From erik at bais.name Thu Dec 23 22:46:15 2021 From: erik at bais.name (Erik Bais) Date: Thu, 23 Dec 2021 21:46:15 +0000 Subject: [address-policy-wg] ripe-682 Transfer Policy Problems In-Reply-To: References: Message-ID: <1A7843A0-A746-4D97-9437-A25D1191E8E1@bais.name> Hi Denis, As the writer of the last transfer policy document, I can put some light in this for you .. ( I hope.. ) The reason for wording like 'a legitmate resource holder' is to include all kind of number resources that holders might have. Being it .. legacy, PI assignments or PA Allocations. Or .. a holder of an AS number. On your statement you cannot transfer a resource unless it is allocated.. would exclude PI assignments .. or Legacy space .. which can also be transferred. There are some documents on the RIPE NCC website that are not policies, but operational procedures, as you already found out .. or how I would state, explanations by interpretation of the RIPE NCC. Like : https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region The way consolidations of resources between LIR's within a member org work, is written and executed by a procedure of the RIPE NCC, not by definition of the transfer policy. That comes originally from the M&A operational procedure that wasn't written down on the public website, but was possible under/by the Dutch legal framework. And when this became pubic knowledge later, explained on the NCC website and even later, adjusted after executive board direction to keep LIR's open for 24 months. ( Yes it was possible in the beginning of the so-called 'final /8 policy' to open a new LIR, request a /22 and merge it back into the initial lir and close the LIR directly.. ) That was seen as a loop-hole .. against the intent of the transfer restriction of the policy and that was the reasoning this was introduced by EB decision. Currently there some operational differences on how 'consolidation' or m&a's are processed within the RIPE NCC and how that expected when the paperwork that is requested by the RIPE NCC and one might expect. If you do a M&A or consolidation, it was (originally) the case that it was required to also sign a Transfer Agreement ( https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfer-agreement-template ) The reasoning behind this practise (as I've been informed by legal from the RIPE NCC ) is to indemnify the RIPE NCC for legal actions .. which in a fact is a bit weird, because the NCC is not a party in the Transfer agreement, but only the executor of an agreement between 2 parties. But in this case the RIPE NCC benefits of legal exclusion on their operation.. But that is a complete different can of worms to discuss. And it actually puts the RIPE NCC in the path of legal action, instead of excluding it as a party. Currently if you do a transfer resources between LIR's of the same member organisation, you are only requested to upload a chamber of commerce document via the website and no other forms are needed anymore. With a M&A, there are notary documents required ... which typically specifies that the number resources are also changing from organisation A to org. B. Those are explained in detail on the RIPE NCC website : https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/required-documents-for-registry-updates And you can see that also the transfer agreement is requested .. even if this is officially NOT a transfer .. but somehow it has been impossible for the RIPE NCC to create a specific template for M&A's ... The only reason for this that I can think of is .. the same legal indemnification that I mentioned earlier .. making the RIPE NCC also here a third party beneficiary to an agreement that it doesn't sign itself. ( looks weird to me .. ) So if you Merge a shell company with 20 LIR's to a company .. with let's say .. 3 LIR's .. you need to select the target LIR .. However .. as the LIR holdership is restricted via the 24 month transfer restriction due to the earlier decision by the board, this isn't executed .. and all LIR's will end up in the target company if the resource wasn't allocated longer than 24 months ago. ( Again .. that isn't how the policy was designed or written .. as M&A's should be possible by transfer policy. ( https://www.ripe.net/participate/policies/proposals/2015-04/?version=4#transferrestrictions ) During the work that we do as an IP broker, we have seen the procedures (and LIR portal interface) change over the passing years .. since the policies were created and implemented. Did we object with the RIPE NCC IPRA (hostmaster) if we found issues like I stated above .. and could argue, but couldn't get the actual topic fixed .. yes .. but in the end the customers need to be serviced .. and they can't wait for their transfer to be on hold, because someone is requesting additional paperwork to be signed. Even if I personally don't agree with it in some cases. One of the weird topics that I see happening with some (Legacy) transfers is that new holders are asked to convert their Legacy space (not owned by the NCC) to be changed to RIPE PA space .. Which basically removes the legacy holder rights of the new holder. And importing their legacy into a RIPE LIR .. and if they would stop paying to the RIPE NCC, they would have the risk of losing their IP space (as it is RIPE PA space now, liked to the membership status ) .. instead of having IP space in their organisations name, regardless if they are a RIPE NCC member or not.. Also this isn't described in the Legacy services policy ( https://www.ripe.net/publications/docs/ripe-639 ) .. and I have no idea why this is being asked on each Legacy transfer to the receiving party ... And I haven't even touched upon inter-rir transfers .. or Legacy transfers itself .. And with this long read .. I come to a close of the statement by itself .. I don't think that the transfer policy by itself is incorrect .. ( but I could be biased ..) ... That the RIPE NCC operates the transfers slightly to its own interpretation I can understand .. and even with the above mentioned topics, I think they do this very good... There is always room for improvement .. and we pick our battles. I'll be more than happy to provide you some insight on transfers from various type of resources and how the LIR portal options work with it. If you don't have access to an LIR, to see how that looks these days. This can be via Zoom / Teams, or if you fancy to come over to our office near Amsterdam for a cup of coffee. Regards, Erik Bais ?On 22/12/2021, 16:01, "address-policy-wg on behalf of denis walker" wrote: Colleagues The Transfer Policy ripe-682 is so vague you can drive a train through the holes in it. I have some questions that I hope someone can answer before Christmas as I would like to propose an amendment to this policy in the new year. "Any legitimate resource holder is allowed to transfer" What does 'legitimate' mean in this context? It is not defined in this policy document. It is no use referring to a dictionary or even some other policy document. It needs to be defined in this policy. If it has no specific meaning in the context of this policy, then the word should be removed. My understanding of a 'policy document' is that it is self contained and consistent. None of the terms: -RIPE NCC Member -LIR -Resource holder are defined anywhere in the Transfer Policy or ripe-733, IPv4 Allocation... A policy may be dependent on another policy being in place. You cannot transfer a resource unless it has been allocated. You cannot allocate a resource unless there is a RIPE NCC Member and an LIR. But you should not have to backtrack through a whole sequence of documents to find out what a term in this policy means. This policy can only work if people understand 'commonly accepted' definitions of these terms. But that is open to interpretation and mis-understanding. That could make legal enforcement of, for example, restrictions more difficult to apply. [As a side issue I have just quickly read through a whole series of documents and forms on becoming a RIPE NCC Member and getting resources. In every document/form I found: -Legal errors -English grammar errors -Procedural errors -Webpage errors The whole process is a complete mess and needs a serious Legal/Comms review.] I found the definition of a Member in one document but nowhere have I found any definition of LIR. These terms are so fundamental to all these policies, to not define them leaves a massive hole in their meaning and authority. These terms seem to be so interchangeable from one paragraph to the next. In some places the wrong term is used. ripe-733 says allocations are made to LIRs ripe-682 says allocations are transferred to members ripe-682 says transfer restrictions apply to resource holders Then we have this document https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers which talks about 'hodership', another term not defined. Then we have this document https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-of-ip-addresses-and-as-numbers/transfers-in-the-ripe-ncc-service-region that conflicts with the Transfer Policy. It also refers to Members as organisations, again without any actual definition. The above document says: "Exception: For transfers between multiple LIR accounts belonging to the same organisation, also referred to as consolidations, the 24 months restriction will only apply once after the resources were received from the RIPE NCC or from another organisation." This is NOT what the Transfer Policy says. The policy makes no mention anywhere of consolidation. The only definition we have of a transfer in any POLICY is this one line: "Allocated resources may only be transferred to another RIPE NCC member." This does not even make sense. A Member cannot 'hold' a resource. Resources are held by Member LIRs. So if a resource is transferred to a Member with 5 LIRs, which one receives it? Does it matter? Is it whichever LIR the Member writes on the transfer request form? Now a consolidation is not a transfer. In the policy a transfer is defined as moving a resource to 'another Member'. So consolidating a resource by moving it from one LIR to another LIR of the same Member is by policy definition, not a transfer. So consolidation is not subject to Transfer Restrictions because it is not a transfer. So all the shell companies that have been set up this year to hoover up the last /24s can now be merged with their parent company and then all the /24s can be consolidated into one LIR. The other LIRs can then be closed. Nothing in this policy document says a /24 allocation must remain for 24 months with the LIR that it was allocated to. It says it cannot be transferred, but mergers are allowed and consolidation is not a transfer. This is even confirmed in a procedural document ripe-758, Transfer of Internet Number Resources... (which doesn't appear to be policy) "Internet number resources that are subject to transfer restrictions imposed by the RIPE Policy "RIPE Resource Transfer Policies", and that are transferred due to a change in a member's business structure, must either remain registered with the original LIR account or be registered with a new LIR account." So merging a shell company with 20 LIRs, each with a /24, with the parent company with a single LIR, allows those 20 /24s to be registered with the single LIR of the parent company and closure of the 20 LIRs. Also ripe-758 introduces yet another term, parties, without any definition or clarity. This whole transfer process is totally confused with contradictory, inconsistent and poorly written documents and policies. cheers denis co-chair DB-WG -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/