Hoarding /22 out of 185/8
All, as we are doing a daily diff of ftp://ftp.ripe.net/ripe/stats/membership/alloclist.txt we observed that something happens right now which was probably not forseen and not inteded by the policy. I thought to make the working group aware. Regards, Fredy / Init7 -------- Weitergeleitete Nachricht -------- Betreff: [allocdelta] New or removed allocations Datum: Tue, 28 Apr 2015 05:00:36 +0200 Von: allocdelta@init7.net * ru.ibulavkin25 Bulavkin Ivan Aleksandrovitch [ADD] 20150224 185.89.104.0/22 ALLOCATED PA [ADD] 20150217 2a03:7f60::/32 * ru.ibulavkin26 Bulavkin Ivan Aleksandrovitch [ADD] 20150217 185.88.96.0/22 ALLOCATED PA [ADD] 20150216 2a03:7da0::/32 * ru.ibulavkin29 Bulavkin Ivan Aleksandrovitch [ADD] 20150409 185.95.100.0/22 ALLOCATED PA * ru.ibulavkin33 Bulavkin Ivan Aleksandrovitch [ADD] 20150422 185.97.76.0/22 ALLOCATED PA * ru.ibulavkin35 Bulavkin Ivan Aleksandrovitch [ADD] 20150414 185.95.228.0/22 ALLOCATED PA * ru.srv2013 Bulavkin Ivan Aleksandrovitch [ADD] 20140930 185.71.144.0/22 ALLOCATED PA [ADD] 20141119 185.77.136.0/22 ALLOCATED PA [ADD] 20141121 185.78.76.0/22 ALLOCATED PA [ADD] 20141031 185.75.132.0/22 ALLOCATED PA [ADD] 20141020 185.73.180.0/22 ALLOCATED PA [ADD] 20141020 185.73.216.0/22 ALLOCATED PA [ADD] 20130626 185.29.124.0/22 ALLOCATED PA [ADD] 20141217 185.81.172.0/22 ALLOCATED PA [ADD] 20130527 2a00:90a0::/32 [ADD] 20141216 185.81.144.0/22 ALLOCATED PA [ADD] 20141001 185.71.212.0/22 ALLOCATED PA [ADD] 20141113 185.76.240.0/22 ALLOCATED PA [ADD] 20141120 185.77.216.0/22 ALLOCATED PA [ADD] 20140624 185.61.220.0/22 ALLOCATED PA [ADD] 20140903 185.68.244.0/22 ALLOCATED PA [ADD] 20141217 185.81.184.0/22 ALLOCATED PA [ADD] 20140604 185.59.232.0/22 ALLOCATED PA [ADD] 20141201 185.79.132.0/22 ALLOCATED PA [ADD] 20140521 185.58.112.0/22 ALLOCATED PA [ADD] 20141128 185.79.76.0/22 ALLOCATED PA [ADD] 20141201 185.79.136.0/22 ALLOCATED PA [ADD] 20140624 185.61.216.0/22 ALLOCATED PA [ADD] 20140829 185.68.184.0/22 ALLOCATED PA [ADD] 20141216 185.24.108.0/22 ALLOCATED PA [ADD] 20141128 185.79.48.0/22 ALLOCATED PA [ADD] 20141120 185.77.220.0/22 ALLOCATED PA
Hello Fredy, Personally i dont understand this list, can you explain more ? Thank you. -- Best regards, Gabriel Voitis
On Tue, 28 Apr 2015, Infinity Telecom SRL wrote:
Hello Fredy,
Personally i dont understand this list, can you explain more ?
The person is starting a lot of LIRs and getting a /22 for each LIR, and then transfering the /22:s to ru.srv2013 LIR. Exactly the kind of behaviour the new proposal that you're objecting to, is trying to make more costly and thus less attractive. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, Apr 28, 2015 at 7:13 AM, Infinity Telecom SRL <ip@infinitytelecom.ro
wrote:
Hello Fredy,
Personally i dont understand this list, can you explain more ?
As I understand it, his concern is that an organization with the same contact person, "Bulavkin Ivan Aleksandrovitch", got allocated 30ish /22 nets, nearly a /17, or around 2‰ (0.2%) of 185/8. -- Jan
The main issue here isn't the amount of IPs someone got by abusing the policy. Sure the 2‰ (0.2%) of 185/8 is negligible, but what would happen if we all did the same? Do you think you are the only ones needing IPs and you are the only ones who worry about their company survival? On the other side, there a people who try to deploy IPv6 and try to overcome the IPv4 exhaustion. This is the way you should also move forward, instead of trying to get more "cheap" IPv4. Remember that for every single /22 you get by abusing the policy, you prohibit a new company to start business in the near future, since the required /22 won't be available any more. Apparently the proposal can't solve all the issues and can't block all kinds of abuse, but I believe it's in the right direction. George On Tue, Apr 28, 2015 at 8:28 AM, Jan Ingvoldstad <frettled@gmail.com> wrote:
On Tue, Apr 28, 2015 at 7:13 AM, Infinity Telecom SRL < ip@infinitytelecom.ro> wrote:
Hello Fredy,
Personally i dont understand this list, can you explain more ?
As I understand it, his concern is that an organization with the same contact person, "Bulavkin Ivan Aleksandrovitch", got allocated 30ish /22 nets, nearly a /17, or around 2‰ (0.2%) of 185/8. -- Jan
* ggiannou@gmail.com (George Giannousopoulos) [Tue 28 Apr 2015, 08:28 CEST]:
Remember that for every single /22 you get by abusing the policy, you prohibit a new company to start business in the near future, since the required /22 won't be available any more.
I believe this argument was dismissed in the previous threadby one of the perpetrators as tragedy of the commons. -- Niels.
This means, thatdealings with opening multiple LIR's, get their /22 allocation and merge this 'new lir's' with other 'host lir' is now in progress at full throttle :( Best regards Tomasz Śląski W dniu 2015-04-28 o 07:13, Infinity Telecom SRL pisze:
Re: [address-policy-wg] Hoarding /22 out of 185/8 Hello Fredy,
Personally i dont understand this list, can you explain more ?
Thank you.
/-- Best regards, Gabriel Voitis /
* -TOM- <tom@kebab.org.pl>
This means, thatdealings with opening multiple LIR's, get their /22 allocation and merge this 'new lir's' with other 'host lir' is now in progress at full throttle :(
Indeed, this person appears to be using the LIR merger procedure, *not* the transfer procedure, to gather the /22s in his main LIR. At least I could not find any of the blocks in question mentioned on <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers>. That in turn means that 2015-01 will have no preventive effect at all. Tore
On Tue, 28 Apr 2015, Tore Anderson wrote:
* -TOM- <tom@kebab.org.pl>
This means, thatdealings with opening multiple LIR's, get their /22 allocation and merge this 'new lir's' with other 'host lir' is now in progress at full throttle :(
Indeed, this person appears to be using the LIR merger procedure, *not* the transfer procedure, to gather the /22s in his main LIR. At least I could not find any of the blocks in question mentioned on <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers>.
That in turn means that 2015-01 will have no preventive effect at all.
But 2015-01 at least says you need to keep the LIR open for 24 months, correct, meaning you have to pay the yearly LIR fee 3 times (one initial and 2 recurring). At least that was my understanding of the proposal. At least the above is what I would like to achieve. -- Mikael Abrahamsson email: swmike@swm.pp.se
* Mikael Abrahamsson <swmike@swm.pp.se>
But 2015-01 at least says you need to keep the LIR open for 24 months, correct, meaning you have to pay the yearly LIR fee 3 times (one initial and 2 recurring). At least that was my understanding of the proposal.
Yes, but it only does this for "normal" transfers per ripe-643 section 5.5. It does not change anything for «Mergers and Acquisitions», because that's not regulated in policy, it is an operational procedure made by the RIPE NCC. https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4... Since the blocks Fredy posted are gathered in a single LIR, yet absent from the table of published transfers, I can only surmise that the person in question is using the M&A procedure to accomplish his goals and not ripe-643 section 5.5 one.
At least the above is what I would like to achieve.
2015-01 unfortunately falls short of the mark, but I don't know it could be fixed since the M&A procedure isn't policy and thus out of scope for the APWG (as I understand it anyway). I'm hoping that the NCC's IA will point out that the M&A loophole remains and maybe advise on how we might go about closing it. Tore
On Tue, Apr 28, 2015 at 09:05:55AM +0200, Tore Anderson wrote:
* Mikael Abrahamsson <swmike@swm.pp.se>
But 2015-01 at least says you need to keep the LIR open for 24 months, correct, meaning you have to pay the yearly LIR fee 3 times (one initial and 2 recurring). At least that was my understanding of the proposal.
Yes, but it only does this for "normal" transfers per ripe-643 section 5.5.
It does not change anything for «Mergers and Acquisitions», because that's not regulated in policy, it is an operational procedure made by the RIPE NCC.
So it appears I was in error assuming that this proposal affects M&A - I partially blame ripe-628 in being confusing and mixing transfers due to M&A and s5.5 transfers in the same doc. I note though that s3.3 of ripe-628 mandates that the full membership fee for the transferring member in the year the transfer takes place in must be paid by the receiving member. This proposal would, at best, add another year's fee to the cost.
I'm hoping that the NCC's IA will point out that the M&A loophole remains and maybe advise on how we might go about closing it.
Given the above and the not inconsiderable paperwork, I can't but think that this really is an edge case. I can't think of any way of closing this without regulating into members' business decisions, maybe someone else can... rgds, Sascha Luck
On Tue, Apr 28, 2015, at 07:52, Tore Anderson wrote:
* -TOM- <tom@kebab.org.pl>
This means, thatdealings with opening multiple LIR's, get their /22 allocation and merge this 'new lir's' with other 'host lir' is now in progress at full throttle :(
Indeed, this person appears to be using the LIR merger procedure, *not* the transfer procedure, to gather the /22s in his main LIR. At least I could not find any of the blocks in question mentioned on <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers>.
Which probbaly means revising the text of 2015-01, and/or adding something similar to the merger procedure. Then again, some basic "needs checking" (checking that the requestor DOES NEED an allocation) would probably help too.
On Tue, 28 Apr 2015, Radu-Adrian FEURDEAN wrote:
On Tue, Apr 28, 2015, at 07:52, Tore Anderson wrote:
* -TOM- <tom@kebab.org.pl>
This means, thatdealings with opening multiple LIR's, get their /22 allocation and merge this 'new lir's' with other 'host lir' is now in progress at full throttle :(
Indeed, this person appears to be using the LIR merger procedure, *not* the transfer procedure, to gather the /22s in his main LIR. At least I could not find any of the blocks in question mentioned on <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers>.
Which probbaly means revising the text of 2015-01, and/or adding something similar to the merger procedure. Then again, some basic "needs checking" (checking that the requestor DOES NEED an allocation) would probably help too.
"Need" shouldn't be a criteria anymore, as we're in "scarcity-mode"/"run-out" mode... One idea could be: «If the LIR doesn't have any other IPv4 allocation made by the RIPE/NCC (before the run-out phase) besides the /22, if a merge process is needed, the /22 is automatically returned to the pool». Cheers, Carlos
Hi, On Tue, 28 Apr 2015, Carlos Friacas wrote: <snipp/>
"Need" shouldn't be a criteria anymore, as we're in "scarcity-mode"/"run-out" mode...
yes exactly.
One idea could be: «If the LIR doesn't have any other IPv4 allocation made by the RIPE/NCC (before the run-out phase) besides the /22, if a merge process is needed, the /22 is automatically returned to the pool».
Defining a policy to stop hoarding while allowing legit. usage is the hard part. Even if you insist that you want to see the prefix in the global routing table and want pingable targets brokers will full any of those requirements with ease. There is propably no way to stop hoarding without also hurting legitimate business. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/
On 2015-04-28 11:30, Christian Kratzer wrote: [...]
Even if you insist that you want to see the prefix in the global routing table
"We" may *want* to see it in the global routing table, but like with all the other prefixes, there's no good reasoning for that expectation. TCP/IP is a technology and that technology is *not* exclusively used for the global Internet. We had that "wish" and discussion in the past (e.g. in the AS# application and PI-"need".) It never worked, neither technically nor admin-wise. That's a non-starter... Wilfried.
and want pingable targets brokers will full any of those requirements with ease.
There is propably no way to stop hoarding without also hurting legitimate business.
Greetings Christian
On Tue, Apr 28, 2015, at 11:25, Carlos Friacas wrote:
"Need" shouldn't be a criteria anymore, as we're in "scarcity-mode"/"run-out" mode...
"Need" should be a criteria again, exactly because we're in run-out mode. Again, "need" starts and ends with "if needed", *withOUT* the "as much as you need" part.
One idea could be: «If the LIR doesn't have any other IPv4 allocation made by the RIPE/NCC (before the run-out phase) besides the /22, if a merge process is needed, the /22 is automatically returned to the pool».
One pretty BAD idea. Not only the small players have a difficult time, but if some of them merge together, this makes sure they stay small. Renumbering is generally delicate for acess customers, and goes to very difficult (adminstratively and process-wise), sometimes limit impossible to running server and services plafroms. The idea is to prevent address hoarding in the first place, not to impose insane limitations on already running things.
On Tue, 28 Apr 2015, Radu-Adrian FEURDEAN wrote: Hi,
On Tue, Apr 28, 2015, at 11:25, Carlos Friacas wrote:
"Need" shouldn't be a criteria anymore, as we're in "scarcity-mode"/"run-out" mode...
"Need" should be a criteria again, exactly because we're in run-out mode. Again, "need" starts and ends with "if needed", *withOUT* the "as much as you need" part.
We agree to disagree :-)
One idea could be: «If the LIR doesn't have any other IPv4 allocation made by the RIPE/NCC (before the run-out phase) besides the /22, if a merge process is needed, the /22 is automatically returned to the pool».
One pretty BAD idea. Not only the small players have a difficult time, but if some of them merge together, this makes sure they stay small.
They would need to remain a LIR in order to keep its /22. What i don't like is the ability for someone to create a new LIR knowing it will be decommissioned later, because the only intent is to "catch" a /22.
Renumbering is generally delicate for acess customers, and goes to very difficult (adminstratively and process-wise), sometimes limit impossible to running server and services plafroms.
Yes, if one organization feels it needs to run away from renumbering, the solution is to become a LIR and get/use its own /22. It will have to do it once, but it will be the last time, provided they always keep their LIR up & running.
The idea is to prevent address hoarding in the first place, not to impose insane limitations on already running things.
Shouldn't be a problem if the LIR wasn't created with the original intent of closing it down after some time... Cheers, Carlos
On Tue, Apr 28, 2015 at 11:05:57AM +0100, Carlos Friacas wrote: Hi
What i don't like is the ability for someone to create a new LIR knowing it will be decommissioned later, because the only intent is to "catch" a /22.
And this is nothing new. Some time ago, during the AP-WG meeting in Tallinn, ICANN representative suggested the same for me. The only intent behind that was to "catch" another v6 /32. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Tue, Apr 28, 2015 at 11:05:57AM +0100, Carlos Friacas wrote:
What i don't like is the ability for someone to create a new LIR knowing it will be decommissioned later, because the only intent is to "catch" a /22.
You can't prove this intent and creating a company with the expectation that it will be bought by someone else is a perfectly legitimate business model. rgds, Sascha Luck
* "Radu-Adrian FEURDEAN" <ripe-wgs@radu-adrian.feurdean.net>
On Tue, Apr 28, 2015, at 07:52, Tore Anderson wrote:
* -TOM- <tom@kebab.org.pl>
This means, thatdealings with opening multiple LIR's, get their /22 allocation and merge this 'new lir's' with other 'host lir' is now in progress at full throttle :(
Indeed, this person appears to be using the LIR merger procedure, *not* the transfer procedure, to gather the /22s in his main LIR. At least I could not find any of the blocks in question mentioned on <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/table-of-transfers>.
Which probbaly means revising the text of 2015-01, and/or adding something similar to the merger procedure. Then again, some basic "needs checking" (checking that the requestor DOES NEED an allocation) would probably help too.
The thing is, since /22 is the minimum allocation size, the requestor only has to need a single - 1 - IPv4 address in order to "need enough" to get a /22. That's the way it has always been - the so-called «no need» proposal didn't really change this; current policy does still require that the requestor intends to make at least 1 assignment from the allocation, and an "assignment" is defined as something that goes into an operational network. Anyway. I think that an LIR is willing to game the policy by creating multiple LIRs and only to merge them, creating this minimum level of "need" for oneself is trivial to do as well. So I'd be very wary of creating policies that are ineffectual at actually preventing the abuse they seek to, while at the same time create pointless overhead and extra paperwork for the vast majority of non-abusive members of the community. Tore
On 2015-04-28, 07:52 , "Tore Anderson" <tore@fud.no> wrote:
* -TOM- <tom@kebab.org.pl>
This means, thatdealings with opening multiple LIR's, get their /22 allocation and merge this 'new lir's' with other 'host lir' is now in progress at full throttle :(
Indeed, this person appears to be using the LIR merger procedure, *not* the transfer procedure, to gather the /22s in his main LIR. At least I could not find any of the blocks in question mentioned on <https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/i pv4-transfers/table-of-transfers>.
That in turn means that 2015-01 will have no preventive effect at all.
It does mean that the RIPE NCC can make changes to the LIR merger procedure to fix this abuse without having to go through the PDP... Alternatively, members could petition the RIPE NCC board to raise the New LIR sign-up fee to 10 or 15 times the current level. That should stop this in its tracks as well and would still not be a huge barrier to new entrants. Alex
On 28/04/15 13:02, Alex Le Heux wrote:
Alternatively, members could petition the RIPE NCC board to raise the New LIR sign-up fee to 10 or 15 times the current level. That should stop this in its tracks as well and would still not be a huge barrier to new entrants.
Hi Alex, Is this really a solution??? I am quite convinced that this will also stop _a lot_ of legitimate companies from becoming LIRs.. RIPE region covers area with very different economical landscapes. €20,000 (or even €30,000) is not a small sum for a start-up in the "rich" side of the region, at the same time it is very prohibitive sum not only for start-up on the "not so rich" side. Just my 2c. -- Sergiusz Paprzycki
On 28.04.2015 16:15, Sergiusz Paprzycki wrote:
On 28/04/15 13:02, Alex Le Heux wrote:
Alternatively, members could petition the RIPE NCC board to raise the New LIR sign-up fee to 10 or 15 times the current level. That should stop this in its tracks as well and would still not be a huge barrier to new entrants.
Hi Alex,
Is this really a solution??? I am quite convinced that this will also stop _a lot_ of legitimate companies from becoming LIRs.. RIPE region covers area with very different economical landscapes. €20,000 (or even €30,000) is not a small sum for a start-up in the "rich" side of the region, at the same time it is very prohibitive sum not only for start-up on the "not so rich" side.
I fully agree with Sergiusz... I think the policy should maybe be adjusted in a way that the only legitimate reason for taking over IP-space is taking over existing customers and continue the service which is running on the IP-Space. The normal procedure of closing a LIR must be withdrawing all resources assigned to that LIR and only if you can present good arguments why a renumbering of customers is not possible, you might keep the address-space. I mean, I also needed to renumber my about 2000 used IPv6-PI addresses when I became LIR as I had to return the IPv6-PI (I know, now there's a proposal on the way to stop that for V6, but that's different thing). -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo@opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
Hi Jens, On 28.04.2015 19:37, Opteamax GmbH wrote:
I fully agree with Sergiusz... I think the policy should maybe be adjusted in a way that the only legitimate reason for taking over IP-space is taking over existing customers and continue the service which is running on the IP-Space.
I was involved in a few mergers and we were always asked to provide documentation. To quote my conversation with the customer service:
Please also submit the following documents:
- an agreement between both companies proving that the network was taken over by ...
In our case (which did not involve networks from the last /8) we were taking over the whole infrastructure from a datacenter site of the former LIR, but did not have an agreement that specifically said so. So we made an additional agreement to fulfill the RIPE NCCs request. So do you really think it is hard to provide such documentation, even if you did not really take over some equipment and/or customers?
The normal procedure of closing a LIR must be withdrawing all resources assigned to that LIR and only if you can present good arguments why a renumbering of customers is not possible, you might keep the address-space.
People who *want* to abuse the system, will just come up with bullshit documentation. How do you propose RIPE NCC does validate if they really need the IPs? Based on what information? Regards André
On Tue, Apr 28, 2015 at 7:50 PM, Andre Keller <ak@list.ak.cx> wrote:
In our case (which did not involve networks from the last /8) we were taking over the whole infrastructure from a datacenter site of the former LIR, but did not have an agreement that specifically said so. So we made an additional agreement to fulfill the RIPE NCCs request. So do you really think it is hard to provide such documentation, even if you did not really take over some equipment and/or customers?
We also took over a DC along with a LIR some time ago. While the process was somewhat tedious and while we had to revisit several documents due to arbitrary bureaucracy, it would have been trivial to do the same in a malicious way. And if you don't believe me that RichiH-a didn't properly take over RichiH-b, I am sure their customer RichiH-c would be happy to provide a letter stating how desperately they need exactly _that_ IP space. I honestly don't know what we could do to improve the situation, but ru.ibulavkin* seems to be _clearly_ abusing the system. The sad part is, I am only surprised by the fact that it took so long. Richard
On 28.04.15 15:02, Alex Le Heux wrote:
Alternatively, members could petition the RIPE NCC board to raise the New LIR sign-up fee to 10 or 15 times the current level. That should stop this in its tracks as well and would still not be a huge barrier to new entrants.
Not 10-20-30-40 times, but up to cost of buying /22 on the market, which is about $10k.
W dniu 2015-05-01 o 20:18, Max Tulyev pisze:
On 28.04.15 15:02, Alex Le Heux wrote:
Alternatively, members could petition the RIPE NCC board to raise the New LIR sign-up fee to 10 or 15 times the current level. That should stop this in its tracks as well and would still not be a huge barrier to new entrants. Not 10-20-30-40 times, but up to cost of buying /22 on the market, which is about $10k.
$10k for /22 is the speculative price of 'virgin space' offered for spammers, who buy /22 and then burn it out on every blacklist in the World, making the addresses practically unusable for long time. Who havinghealthy brain is buying /22 for $10k, for 'normal' purposes, if he can buy with no questions /22 by just opening a new LIR? -- Tomasz Śląski tom@kebab.org.pl
Yes, that's the price of *clean* IPv4 /22 on the market, without any trackable criminal history. Yes, spammers *can* register a new LIR for /22. And I believe they (or somebody for them) *do* that. No, people buy clean /22 *not* only for sendind spam. Good business want good IPs and wish to pay some money for that. BUT, some good companies don't want/can't start-up a horde of LIRs using a horde of shell companies, and one /22 is as small as not visible for them. They need /16 for example, and wish to pay some money for just buying a network. The price I know is from $6 to $15 per IP. That's the source of that hoarding /22 business. If you want to eliminate it really - the only real way is to kill a profit. On 04.05.15 14:50, Tomasz SLASKI wrote:
$10k for /22 is the speculative price of 'virgin space' offered for spammers, who buy /22 and then burn it out on every blacklist in the World, making the addresses practically unusable for long time. Who havinghealthy brain is buying /22 for $10k, for 'normal' purposes, if he can buy with no questions /22 by just opening a new LIR?
What's wrong in /22 hoarding? How does it abuse the system? 06 Май 2015 г. 9:30 пользователь "Max Tulyev" <mtl@netassist.ua> написал:
Yes, that's the price of *clean* IPv4 /22 on the market, without any trackable criminal history. Yes, spammers *can* register a new LIR for /22. And I believe they (or somebody for them) *do* that. No, people buy clean /22 *not* only for sendind spam. Good business want good IPs and wish to pay some money for that. BUT, some good companies don't want/can't start-up a horde of LIRs using a horde of shell companies, and one /22 is as small as not visible for them. They need /16 for example, and wish to pay some money for just buying a network. The price I know is from $6 to $15 per IP.
That's the source of that hoarding /22 business. If you want to eliminate it really - the only real way is to kill a profit.
On 04.05.15 14:50, Tomasz SLASKI wrote:
$10k for /22 is the speculative price of 'virgin space' offered for spammers, who buy /22 and then burn it out on every blacklist in the World, making the addresses practically unusable for long time. Who havinghealthy brain is buying /22 for $10k, for 'normal' purposes, if he can buy with no questions /22 by just opening a new LIR?
W dniu 2015-05-06 o 08:53, Aleksey Bulgakov pisze:
What's wrong in /22 hoarding? How does it abuse the system?
It's speeds-up the whole IPv4 depletion, and heats the speculative prices. IMO, the situation will continue as long as the IPv4 prices will be accepted by the market. After crossing the threshold of pain, people will notice that it is better to migrate to IPv6 instead of paying sick money for antiquitie numbers. Unfortunately, the pain threshold is very high, because there is still lot of equipment bought for millions $ that you have to throw to scrap dump, to say IPv4 goodbye permanently. Regards, -- Tomasz Śląski tom@kebab.org.pl
On Wed, May 6, 2015, at 09:11, Tomasz SLASKI wrote:
IMO, the situation will continue as long as the IPv4 prices will be accepted by the market. After crossing the threshold of pain, people will notice that it is better to migrate to IPv6 instead of paying sick money for antiquitie numbers. Unfortunately, the pain threshold is very high, because there is still lot of equipment bought for millions $ that you have to throw to scrap dump, to say IPv4 goodbye permanently.
Well, today the problem does NOT end with "deploy IPv6". An an ISP you still have to do CGN and in a number of countries conserve TCP/UDP connection logs for some time (12/24/36 months). No IPv4 at all = out of business. If you also do "enterprise access", you can't even start your business without IPv4 space. For server hosting providers, it's even worse, IPv6 being close to no help at all (you still need 1 public IPv4 per server sold, for the moment IPv6 doesn't help in any way - it is a longer-term solution, that for the monent only helps "the others"). Then yes, all that hardware that doesn't work without IPv4, but you still have "non-public" space for that as a last resort solution. An then there's all the small but numerous companies that will "never ever in hell" deploy anything if there is not explicit customer demand - and customers rarely make an explicit demand for IPv6, and when they do it's generally "1 in 1000". Point is, even for people that DO deploy IPv6, there is still a need of v4 adresses for quite some time. The "hit the wall hard, ASAP" strategy (like in ARIN or LACNIC land) doesn't seem to be the solution favoured by the community in RIPE-land.
Am 2015-05-06 11:05, schrieb Radu-Adrian FEURDEAN:
Point is, even for people that DO deploy IPv6, there is still a need of v4 adresses for quite some time. The "hit the wall hard, ASAP" strategy (like in ARIN or LACNIC land) doesn't seem to be the solution favoured by the community in RIPE-land.
And exactly this is the reason why the /22-policy is as it is and is not meant to be bypassed by setting up LIRs and transfering. Even if your "default" is IPv6, you'll need at least this few IPv4 to be able to run CGN etc. I just had this mail (below) in my ticketsystem
Hello.
As you know, the RIPE NCC can only provide one final /22 to your LIR because it is currently allocating address space from the last /8 of IPv4 addresses.
However the RIPE NCC allows to get IPv4 addresses from other LIR. Our company has LIR status and ready to transfer such addresses to your LIR. This operation is approved by the RIPE NCC and absolutely legal.
The blocks are absolutely clean, haven't been in usage, are absent in any blacklist.
If you have any questions, don't hesitate to ask me. Simply answer to this letter and you will get the answer shortly.
... and reading this I think the policy must be strictly changed. I do not exactly know the wording of RIPE membership rules, but if you set up a "Verein" in Germany (and this is more or less the type which matches best the legal form RIPE NCC has) you are recommended to put something like "each and every person who is willingly doing any harm to the club, it's reputation or other members is to be kicked out without any right for compensations. All rights this person has be being member are immediately withdrawn. The exclusion from the club does not reduce the any regress against the excluded member". I see, that it is not possible to prevent every bypassing, but I think someone who is even spaming and advertising sale of resources shall be kicked out RIPE NCC immediately and all resources this person or enterprise ever requested should be withdrawn! I am not saying that people opening a second LIR and later merges this second LIR back after a while for which ever reason (e.g. second LIRs purpose did not launch successfully) should not be hit by this rule; sometimes plans don't work out. But if it is obviously that someone is doing it "regualary" this IS obviously and can be seen easily by membership application and here we absolutely should stop the abuse. BR Jens
On Wed, May 6, 2015, at 12:00, Opteamax GmbH - RIPE-Team wrote:
... and reading this I think the policy must be strictly changed. I do not exactly know the wording of RIPE membership rules, but if you set up a "Verein" in Germany (and this is more or less the type which matches best the legal form RIPE NCC has) you are recommended to put something like "each and every person who is willingly doing any harm to the club, it's reputation or other members is to be kicked out without any right for compensations. All rights this person has be being member are immediately withdrawn. The exclusion from the club does not reduce the any regress against the excluded member".
Except this is not policy (done by the RIPE community), but a RIPE NCC affair. Changes like this are to be decided in general meeting with approval from a majority of members (including the incriminated LIRs and people that may not understand what this is all about). Discussing such issues shoud be done ont the APWG mailing list, but on the members-discuss or a membership-related mailing list. Please also take into account that people having a right to vote at the NCC GM are not always the same as the ones active here. But the idea is not bad.
I see, that it is not possible to prevent every bypassing, but I think someone who is even spaming and advertising sale of resources shall be kicked out RIPE NCC immediately and all resources this person or enterprise ever requested should be withdrawn!
For the time being it is a little difficult to enforce, and will yield some highly undesirable consequences.
On 06/05/2015 08:11, "Tomasz SLASKI" <tom@kebab.org.pl> wrote:
IMO, the situation will continue as long as the IPv4 prices will be accepted by the market. After crossing the threshold of pain, people will notice that it is better to migrate to IPv6 instead of paying sick money for antiquitie numbers. Unfortunately, the pain threshold is very high, because there is still lot of equipment bought for millions $ that you have to throw to scrap dump, to say IPv4 goodbye permanently.
Tomasz Until the major ISPs start turning on IPv6 this is going to be a “chicken and egg” scenario I asked all the large Irish ISPs what they were doing and they essentially said they had enough IPv4 space so they didn’t see any need to switch on IPv6 *sigh* Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social Random Stuff: http://michele.irish ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845
Yes, that's the price of *clean* IPv4 /22 on the market, without any trackable criminal history. Yes, spammers *can* register a new LIR for /22. And I believe they (or somebody for them) *do* that. No, people buy clean /22 *not* only for sendind spam. Good business want good IPs and wish to pay some money for that. BUT, some good companies don't want/can't start-up a horde of LIRs using a horde of shell companies, and /22 is as small as not visible for them. They need /16 for example, and wish to pay some money for On 04.05.15 14:50, Tomasz SLASKI wrote:
$10k for /22 is the speculative price of 'virgin space' offered for spammers, who buy /22 and then burn it out on every blacklist in the World, making the addresses practically unusable for long time. Who havinghealthy brain is buying /22 for $10k, for 'normal' purposes, if he can buy with no questions /22 by just opening a new LIR?
I thought to make the working group aware.
Great, finally IPv4 is becoming a market so hot, that deploying IPv6 seems to be the better option. I would like to see more like this, let them battle for the last bites of the cadaver. Good to know that ru.ibulavkin25 has at least 3 /32. They sure will be able to serve the endpoints they deploy the tiny bit of legacy IP space they have using IPv6, too. Dan
Reminds me of the old joke that IPv4 will never run out, because nobody will be able to afford that last IPv4 address :-) -----Ursprüngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Im Auftrag von Dan Lüdtke Gesendet: Montag, 4. Mai 2015 17:52 An: address-policy-wg@ripe.net Betreff: Re: [address-policy-wg] Hoarding /22 out of 185/8
I thought to make the working group aware.
Great, finally IPv4 is becoming a market so hot, that deploying IPv6 seems to be the better option. I would like to see more like this, let them battle for the last bites of the cadaver. Good to know that ru.ibulavkin25 has at least 3 /32. They sure will be able to serve the endpoints they deploy the tiny bit of legacy IP space they have using IPv6, too. Dan
participants (27)
-
-TOM-
-
Aleksey Bulgakov
-
Alex Le Heux
-
Andre Keller
-
Carlos Friacas
-
Christian Kratzer
-
Dan Lüdtke
-
Fredy Kuenzler
-
George Giannousopoulos
-
Infinity Telecom SRL
-
Jan Ingvoldstad
-
Max Tulyev
-
Max Tulyev
-
Michele Neylon - Blacknight
-
Mikael Abrahamsson
-
niels=apwg@bakker.net
-
Opteamax GmbH
-
Opteamax GmbH - RIPE-Team
-
Piotr Strzyzewski
-
Radu-Adrian FEURDEAN
-
Richard Hartmann
-
Sascha Luck [ml]
-
Sergiusz Paprzycki
-
Silvia Hagen
-
Tomasz SLASKI
-
Tore Anderson
-
Wilfried Woeber