Hello, I 100% agree with you ! As many resources one LIR consumes as bigger membership fee should be. Even to better optimize resources usage, the fee can be calculated on /24 basis. example: /17 = 128 x /24 fee = (128-4)*350 = 43 400 euro/year fee P.S. in your example should be: (32-1)*1400 = 39 200 euro. Ivaylo Josifov Varteh LTD Varna Bulgaria On Wed, 16 Jan 2019, TrustHost wrote:
Hi. I think it would be great if the payment depends on the quantity the resources for one account. It would help to return unused IPv4 in free pool for new business. The companies, who really use big networks won't notice such changes. But who received the resources before 2012 and has unused /19 and maybe more will think if they really need such big blocks. For example we can implement the next charging scheme. If one account has more than /20 (not equivalent 4x/22 or the blocks were allocated before 2012) the next /22 ownership will cost some price (e.g. 1400 euro). For example: There is /17 IPv4 block for one LIR account. /17 = 32x/22. The total price for this account is (32-4)*1400 = 39 200 euro. I think the members must have equal rights, regardless of the year of the membership started. ------------------ Kind regards, Boris Loginov TrustHost LLC
Hello A better solution would be to promote ipv6 and maybe offer incentives for ipv6 ready LIRs (or penalize LIRs that are not ipv6 ready). We need to make sure any ipv4 address is mapped to an ipv6 address so we can finally start to phase ipv4 out. Bogdan On Jan 17, 2019, 8:54 AM, at 8:54 AM, ivaylo <ivaylo@bglans.net> wrote:
Hello,
I 100% agree with you !
As many resources one LIR consumes as bigger membership fee should be.
Even to better optimize resources usage, the fee can be calculated on /24 basis.
example: /17 = 128 x /24 fee = (128-4)*350 = 43 400 euro/year fee
P.S. in your example should be: (32-1)*1400 = 39 200 euro.
Ivaylo Josifov Varteh LTD Varna Bulgaria
On Wed, 16 Jan 2019, TrustHost wrote:
Hi. I think it would be great if the payment depends on the quantity the resources for one account. It would help to return unused IPv4 in free pool for new business. The companies, who really use big networks won't notice such changes. But who received the resources before 2012 and has unused /19 and maybe more will think if they really need such big blocks. For example we can implement the next charging scheme. If one account has more than /20 (not equivalent 4x/22 or the blocks were allocated before 2012) the next /22 ownership will cost some price (e.g. 1400 euro). For example: There is /17 IPv4 block for one LIR account. /17 = 32x/22. The total price for this account is (32-4)*1400 = 39 200 euro. I think the members must have equal rights, regardless of the year of the membership started. ------------------ Kind regards, Boris Loginov TrustHost LLC
------------------------------------------------------------------------
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/admin%40redcluster.or...
Hello, There are no doubts the future belongs to IPV6. But if we have no good scheme to control resource usage, what guarantee us 10-15 years after full ipv6 deploy we will be in same situation as now. Even the fact IPV6 have 65535^8 addresses if these resources are spilled unuzed and not optimized will over again. What better control mechanism could be than money ? To be realistic I cant imagine how in next 10 years IPV6 will be fully deployed and will full substitute IPV4 from technical point of view. No matter what penalize or encouragement to LIRs will have to use IPV6, there are huge number of internet services that cant be easyly migrated. The migration will happen naturaly when there are no other options, pushing it will make only difficulties to Internet users and providers (all of us). For me IP market is one big crap. Internet Resources must go where they are needed, not to sit locked and unused, because somebody want to earn easy money from this (speculators to go on exchanges here are no room for them). RIPE must take back all these nets which sits on the market, because obviously they are free and not used. I am pretty sure there are big number of unoptimize resources LIRs hold. How many from you try to use 90% + from your resources I bet the number can fit in 12bits. But if have to pay for something not use, that number will grow a lot. And next time when your bussiness step up, you will have from where to get needed resources. My opinion about charging scheme change for 2019 is positive. If your bussiness dont allow to pay 1400 euro in once, then you should not be LIR. There are and other options for you. With the scheme change maybe some smaller speculants that try to rent/sell resources only will gone. Ivaylo Josifov Varteh LTD Varna Bulgaria On Thu, 17 Jan 2019, Redcluster wrote:
Hello
A better solution would be to promote ipv6 and maybe offer incentives for ipv6 ready LIRs (or penalize LIRs that are not ipv6 ready).
We need to make sure any ipv4 address is mapped to an ipv6 address so we can finally start to phase ipv4 out.
Bogdan
On Jan 17, 2019, at 8:54 AM, ivaylo <ivaylo@bglans.net> wrote:
Hello, I 100% agree with you ! As many resources one LIR consumes as bigger membership fee should be. Even to better optimize resources usage, the fee can be calculated on /24 basis. example: /17 = 128 x /24 fee = (128-4)*350 = 43 400 euro/year fee P.S. in your example should be: (32-1)*1400 = 39 200 euro. Ivaylo Josifov Varteh LTD Varna Bulgaria On Wed, 16 Jan 2019, TrustHost wrote: Hi. I think it would be great if the payment depends on the quantity the resources for one account. It would help to return unused IPv4 in free pool for new business. The companies, who really use big networks won't notice such changes. But who received the resources before 2012 and has unused /19 and maybe more will think if they really need such big blocks. For example we can implement the next charging scheme. If one account has more than /20 (not equivalent 4x/22 or the blocks were allocated before 2012) the next /22 ownership will cost some price (e.g. 1400 euro). For example: There is /17 IPv4 block for one LIR account. /17 = 32x/22. The total price for this account is (32-4)*1400 = 39 200 euro. I think the members must have equal rights, regardless of the year of the membership started. ------------------ Kind regards, Boris Loginov TrustHost LLC
____________________________________________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/admin%40 redcluster.org
Hi, On Thu, Jan 17, 2019 at 01:49:47PM +0200, ivaylo wrote:
There are no doubts the future belongs to IPV6. But if we have no good scheme to control resource usage, what guarantee us 10-15 years after full ipv6 deploy we will be in same situation as now. Even the fact IPV6 have 65535^8 addresses if these resources are spilled unuzed and not optimized will over again. What better control mechanism could be than money ?
IPv6 utilization seems to be well under control. The policies are working nicely - every ISP and every end customer can have large amounts of IPv6 networks, but still we're only scratching on the first 1% of the first 1/8 of the IPv6 address space (5 /12 out of 2000::/3 allocated to RIRs, but by no means fully utilized). With most "really large" players already having "amazingly large" IPv6 allocations. The point about IPv6 is not "conserve! conserve!" but "use these nice easily accessible masses of addresses and GO AND ROLL OUT IPv6!" Gert Doering -- APWG chair -- 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
Sorry to hijack this thread, but I'd disagree with the "policies are working nicely" comment, right now I'm really struggling to get RIPE to accept my request for a larger-than-/29 allocation. The simple math that a /29 only provides room for ~500K subscribers, when coupled with RIPE's own RIPE-690 BCOP `recommendation of /48 PD assignments, apparently isn't sufficient justification. I agree with your comment that the point of IPv6 isn't to "conserve! conserve!", however in my experience it seems that RIPE does not agree with us. RIPE is still placing far too much pressure on the LIR to justify the network design and geographical topology of their network, citing RIPE-707 Section 3.5. Right now it is easier for me to simply continue assigning /56 prefix delegations to end-users, instead of fighting RIPE. -Rich On 17/01/2019, 12:29, "members-discuss on behalf of Gert Doering" <members-discuss-bounces@ripe.net on behalf of gert@space.net> wrote: IPv6 utilization seems to be well under control. The policies are working nicely - every ISP and every end customer can have large amounts of IPv6 networks, but still we're only scratching on the first 1% of the first 1/8 of the IPv6 address space (5 /12 out of 2000::/3 allocated to RIRs, but by no means fully utilized). With most "really large" players already having "amazingly large" IPv6 allocations. The point about IPv6 is not "conserve! conserve!" but "use these nice easily accessible masses of addresses and GO AND ROLL OUT IPv6!" Gert Doering -- APWG chair Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
Hi, On Mon, Jan 21, 2019 at 04:11:58PM +0000, Patterson, Richard (Sky Network Services (SNS)) wrote:
Sorry to hijack this thread, but I'd disagree with the "policies are working nicely" comment, right now I'm really struggling to get RIPE to accept my request for a larger-than-/29 allocation.
People always bitch when NCC hostmasters ask questions about their nice addressing plans. Usually when then numbers are right people get their addresses in the end. So, RIPE-707 5.1.2 says "LIRs may qualify for an initial allocation greater than /29 by submitting documentation that reasonably justifies the request. If so, the allocation size will be based on the number of users, the extent of the LIR infrastructure, the hierarchical and geographical structuring of the LIR, the segmentation of infrastructure for security and the planned longevity of the allocation" which, for user assignments of a /48, should be possible if you can demonstrate more than 100.000 customers and a reasonably structured network with internal aggregation levels. But this is something better discussed in the address-policy list, or possible in private mails among AP chairs and IPRAs if you want. It's not nullifying my argument, though - people have received large address blocks (and quite a number of them), *and we're not close to running out of IPv6 space*. The latter part was the relevant bit in the context of the statement I quoted.
The simple math that a /29 only provides room for ~500K subscribers, when coupled with RIPE's own RIPE-690 BCOP `recommendation of /48 PD assignments, apparently isn't sufficient justification.
I agree with your comment that the point of IPv6 isn't to "conserve! conserve!", however in my experience it seems that RIPE does not agree with us. RIPE is still placing far too much pressure on the LIR to justify the network design and geographical topology of their network, citing RIPE-707 Section 3.5.
"RIPE" neither agrees nor disagrees with anything. "The RIPE NCC" might disagree, but usually it's a question of proper arguments. The large assignments to DTAG, de.government, etc., didn't happen "just so" either, but required quite a bit of documentation and showing numbers. 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
Hi Gert, On 21/01/2019, 16:51, "Gert Doering" <gert@space.net> wrote: It's not nullifying my argument, though - people have received large address blocks (and quite a number of them), *and we're not close to running out of IPv6 space*. The latter part was the relevant bit in the context of the statement I quoted. Absolutely, this was a slightly off-topic anecdote regarding your initial comment. "RIPE" neither agrees nor disagrees with anything. "The RIPE NCC" might disagree, but usually it's a question of proper arguments. The large assignments to DTAG, de.government, etc., didn't happen "just so" either, but required quite a bit of documentation and showing numbers. I'm not arguing that large allocations should be made without scrutiny, however it feels that the scrutiny currently imposed by the RIPE NCC is overly zealous and in some regards, contradictory to certain parts of RIPE policy. Happy to continue this particular discussion on the APWG list, or privately with the chairs. -Richard Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
On 21/01/2019 17:11, Patterson, Richard (Sky Network Services (SNS)) wrote:
Sorry to hijack this thread, but I'd disagree with the "policies are working nicely" comment, right now I'm really struggling to get RIPE to accept my request for a larger-than-/29 allocation.
The simple math that a /29 only provides room for ~500K subscribers, when coupled with RIPE's own RIPE-690 BCOP `recommendation of /48 PD assignments, apparently isn't sufficient justification.
Hi, I've heard this argument from other people also. I would expect that getting /32 or /29 should be easy for initial testing and also for small or mid-sized operators to deploy in production when they choose so. If big operator decides to deploy IPv6 to all their customers and can prove that they have for example 10 million customers that they would like to enable with /48 subnets - then this should be more than enough for RIPE NCC IPRa's to give whatever is needed to do that. If you can't prove that you have such a customer base and you *plan* to have them, then the usual bumpy and windy way of proving it applies - but if you *already* have users and infrastructure - why making deployment of IPv6 harder for operators when they decide to do it??? Confused, Jan
On 19/02/2019, 10:10, "members-discuss on behalf of Jan Zorz - Go6" <members-discuss-bounces@ripe.net on behalf of jan@go6.si> wrote: I've heard this argument from other people also. I would expect that getting /32 or /29 should be easy for initial testing and also for small or mid-sized operators to deploy in production when they choose so. If big operator decides to deploy IPv6 to all their customers and can prove that they have for example 10 million customers that they would like to enable with /48 subnets - then this should be more than enough for RIPE NCC IPRa's to give whatever is needed to do that. If you can't prove that you have such a customer base and you *plan* to have them, then the usual bumpy and windy way of proving it applies - but if you *already* have users and infrastructure - why making deployment of IPv6 harder for operators when they decide to do it??? This is where the problem (for me at least) was, there's a third middle state not mentioned above, nor properly covered by policy. An operator that isn't just doing initial testing, doesn't have a current deployment to justify based on current policy, but is deploying new infrastructure at scale. Said operator shouldn't have to build a design to intentionally hit capacity just so as to have justification for a larger allocation. We're perhaps a less common case with a greenfield deployment, large IPv6-only focused deployment from day one, large scale forecasts and proven track record. We did get there in end, but it was a rather frustrating process with lots of back and forth emails via a ticketing system, conference calls, challenging and requests for commercially sensitive information around forecasts and topology deployments (without RIPE being willing to sign NDAs). I was very close to giving up and designing around /56 PDs for customers instead of /48s. It felt like the IPv4-conservative approach was being applied to IPv6, and that kind of defeats the purpose IMO. -Richard Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
On 19/02/2019 12:44, Patterson, Richard (Sky Network Services (SNS)) wrote:
We're perhaps a less common case with a greenfield deployment, large IPv6-only focused deployment from day one, large scale forecasts and proven track record. We did get there in end, but it was a rather frustrating process with lots of back and forth emails via a ticketing system, conference calls, challenging and requests for commercially sensitive information around forecasts and topology deployments (without RIPE being willing to sign NDAs). I was very close to giving up and designing around /56 PDs for customers instead of /48s.
This shouldn't be the experience you get if you are enthusiastic about deploying IPv6 to end customers. This is just plain wrong. I understand that if we stick strictly to the policy this can be interpreted as a valid process, but I still think this shouldn't be the default in such cases.
It felt like the IPv4-conservative approach was being applied to IPv6, and that kind of defeats the purpose IMO.
Agreed 100%. Cheers, Jan
From: Patterson, Richard (Sky Network Services (SNS)) Sent: Tuesday, February 19, 2019 12:44 PM [snip]
It felt like the IPv4-conservative approach was being applied to IPv6, and that kind of defeats the purpose IMO.
I have experienced this as well. For technical reasons (not convenience), I needed another /29 (or rather 6 /32's). This turned out to take too long and too much of my time, so I gave up and opened another LIR simply for the /29 IPv6. Of course that meant I had to buy one less /22 IPv4 on the free market, so the tight IPv6 policies directly caused faster depletion of IPv4. Though I don't know whether this happens often enough to be significant, it's still ass-backwards. -- Regards, Terrence Koeman, PhD/MTh/BPsy Darkness Reigns (Holding) B.V. Please quote relevant replies.
On 19/02/2019, 14:52, "Terrence Koeman" <terrence@darkness-reigns.com> wrote: I have experienced this as well. For technical reasons (not convenience), I needed another /29 (or rather 6 /32's). This turned out to take too long and too much of my time, so I gave up and opened another LIR simply for the /29 IPv6. Of course that meant I had to buy one less /22 IPv4 on the free market, so the tight IPv6 policies directly caused faster depletion of IPv4. Though I don't know whether this happens often enough to be significant, it's still ass-backwards. You know the policy (or perhaps the interpretation/implementation of the policy) is broken when it's easier for someone to spin up a new company and LIR than it is to get a larger IPv6 allocation. Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD
On Thu Jan 17, 2019 at 01:49:47PM +0200, ivaylo wrote:
There are no doubts the future belongs to IPV6. But if we have no good scheme to control resource usage, what guarantee us 10-15 years after full ipv6 deploy we will be in same situation as now
See mailing list for previous discussions. tl;dr - not a problem
To be realistic I cant imagine how in next 10 years IPV6 will be fully deployed and will full substitute IPV4 from technical point of view
When people really can't get any v4 they will deal with it. People will sell nat boxes designed to make translation easy to set up for the things that really have to stay on v4 and talk to limited v6 things. For everything else the devices will be upgraded/replaced with something that can v6.
The migration will happen naturaly when there are no other options, pushing it will make only difficulties to Internet users and providers (all of us).
It'll be painful whenever it happens so may as well get on with it now
For me IP market is one big crap. Internet Resources must go where they are needed, not to sit locked and unused, because somebody want to earn easy money from this (speculators to go on exchanges here are no room for them). RIPE must take back all these nets which sits on the market, because obviously they are free and not used.
No point, it just delays migration to v6 by a short amount
My opinion about charging scheme change for 2019 is positive. If your bussiness dont allow to pay 1400 euro in once, then you should not be LIR. There are and other options for you. With the scheme change maybe some smaller speculants that try to rent/sell resources only will gone.
Agreed, those who are troubled by the changes can blame the speculators. The speculators can shut up you've made enough money scamming resources at everyone elses expense, pay your annual bills. brandon
Hello, sorry but that type of billing is totally nonsense. You obvisously never calculated this with real data. Let me do it for you: According to ftp://ftp.ripe.net/ripe/stats/delegated-ripencc-extended-latest RIPE currently assigned 817101048 IP addresses for real-use (excluding reserved and free etc.). That equals to roughly 3191800 /24's. There are currently 20806 LIR's ( https://labs.ripe.net/statistics/number-of-lirs), if each one is getting a /22 free, that means we have to deduct 83224 /24's from above figure. That makes it 3108576 /24's which should be billed (according to you). 3108576*350 = 1.088.001.600,00 Euros. Yes, thats 1 billion euros. RIPE's budget for 2018 was (projected) to be 26 million euros: https://www.ripe.net/publications/docs/ripe-693 As you can see this is utterly nonsense. As you might know, any surplus the RIPE NCC generates (at the end of the fiscal year) will be re- distributed to the members as RIPE is a association and not a company in regular terms. Or are you trying to actually get paid from RIPE for using little count of IPv4 addresses? Anything that is money related will *not* help to get IPv4 back or solve this with the current form of membership and RIPE. There are plenty of other ways (some of which have been proposed here) that are a much better idea (migrating to IPv6 being the ultimate one). -J Am Mittwoch, den 16.01.2019, 17:22 +0200 schrieb ivaylo:
Hello,
I 100% agree with you !
As many resources one LIR consumes as bigger membership fee should be.
Even to better optimize resources usage, the fee can be calculated on /24 basis.
example: /17 = 128 x /24 fee = (128-4)*350 = 43 400 euro/year fee
P.S. in your example should be: (32-1)*1400 = 39 200 euro.
Ivaylo Josifov Varteh LTD Varna Bulgaria
On Wed, 16 Jan 2019, TrustHost wrote:
Hi. I think it would be great if the payment depends on the quantity the resources for one account. It would help to return unused IPv4 in free pool for new business. The companies, who really use big networks won't notice such changes. But who received the resources before 2012 and has unused /19 and maybe more will think if they really need such big blocks. For example we can implement the next charging scheme. If one account has more than /20 (not equivalent 4x/22 or the blocks were allocated before 2012) the next /22 ownership will cost some price (e.g. 1400 euro). For example: There is /17 IPv4 block for one LIR account. /17 = 32x/22. The total price for this account is (32-4)*1400 = 39 200 euro. I think the members must have equal rights, regardless of the year of the membership started. ------------------ Kind regards, Boris Loginov TrustHost LLC
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/r ipe%40probe-networks.de
On 1/16/19 2:16 PM, TrustHost wrote:
Hi. I think it would be great if the payment depends on the quantity the resources for one account. It would help to return unused IPv4 in free pool for new business. The companies, who really use big networks won't notice such changes. But who received the resources before 2012 and has unused /19 and maybe more will think if they really need such big blocks. For example we can implement the next charging scheme. If one account has more than /20 (not equivalent 4x/22 or the blocks were allocated before 2012) the next /22 ownership will cost some price (e.g. 1400 euro). For example: There is /17 IPv4 block for one LIR account. /17 = 32x/22. The total price for this account is (32-4)*1400 = 39 200 euro. I think the members must have equal rights, regardless of the year of the membership started.
I do not agree. As a company that has to keep at least 10 /22 available at all times, this means that I would be paying more, just because I need to make sure the company can grow fast enough, when it needs to. Buying and transferring IPs takes weeks with all the paperwork, so the only way we can keep growing is by keeping IPs in reserve. And we and our clients would need to pay for that. -- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hackman@jabber.org ICQ: 7556201 IRC: hackman @ irc.freenode.net Mobile: +359 886 660 270
Hello, Marian I think TrustHost just gave an example. If there are charging scheme based on resources the LIR needs, the fees will be different. For example if we took all incomes from membership for 2018 and all nets allocated for RIPE region... (SUM amount of money for 2018 collected from membership anual fees) / (All /22 nets allocated for RIPE region) = fee for one /22 So the fee for 10 x /22 will be much less than 14000 EURO per year as it is now if you have 10 opened LIRs. Also if RIPE managing freed resources, dedicating new such ro your bussiness needs will be much faster I beleave. Ivaylo Josifov Varteh LTD Varna Bulgaria On Thu, 17 Jan 2019, Marian Marinov wrote:
On 1/16/19 2:16 PM, TrustHost wrote:
Hi. I think it would be great if the payment depends on the quantity the resources for one account. It would help to return unused IPv4 in free pool for new business. The companies, who really use big networks won't notice such changes. But who received the resources before 2012 and has unused /19 and maybe more will think if they really need such big blocks. For example we can implement the next charging scheme. If one account has more than /20 (not equivalent 4x/22 or the blocks were allocated before 2012) the next /22 ownership will cost some price (e.g. 1400 euro). For example: There is /17 IPv4 block for one LIR account. /17 = 32x/22. The total price for this account is (32-4)*1400 = 39 200 euro. I think the members must have equal rights, regardless of the year of the membership started.
I do not agree. As a company that has to keep at least 10 /22 available at all times, this means that I would be paying more, just because I need to make sure the company can grow fast enough, when it needs to.
Buying and transferring IPs takes weeks with all the paperwork, so the only way we can keep growing is by keeping IPs in reserve. And we and our clients would need to pay for that.
-- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hackman@jabber.org ICQ: 7556201 IRC: hackman @ irc.freenode.net Mobile: +359 886 660 270
On Thu, Jan 17, 2019 at 12:59:52PM +0100, Marian Marinov wrote:
I do not agree. As a company that has to keep at least 10 /22 available at all times, this means that I would be paying more, just because I need to make sure the company can grow fast enough, when it needs to. Buying and transferring IPs takes weeks with all the paperwork, so the only way we can keep growing is by keeping IPs in reserve. And we and our clients would need to pay for that.
Sitting on a good amount of IPv4 has value for you but you and your customers do not agree to pay for it ?
participants (11)
-
Brandon Butterworth -
Denis Fondras -
Gert Doering -
ivaylo -
Jan Zorz - Go6 -
Jonas Frey -
Marian Marinov -
Patterson, Richard (Sky Network Services (SNS)) -
Redcluster -
Terrence Koeman -
TrustHost