This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] stockpiling IPv6
- Previous message (by thread): [address-policy-wg] stockpiling IPv6
- Next message (by thread): [address-policy-wg] stockpiling IPv6
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Aleksey Bulgakov
aleksbulgakov at gmail.com
Wed Oct 28 13:33:26 CET 2020
Hi all. What's bad if someone has several /29 IPv6? Are they running out? How many IPv6 has each RIR? In total the mount of IPv4 is about 4.29 billions against IPv6 with the mount 3.4*10^38. I understand that the NCC tries to find additional funds and implements additional restrictions to force their members to make additional spending. But we should carefully implement new policies. --- Kind regards, Alex ср, 28 окт. 2020 г., 14:05 JORDI PALET MARTINEZ via address-policy-wg < address-policy-wg at ripe.net>: > Hi all, > > After Nikolas presentation today, I've been thinking on possible ways to > resolve this, so before sending a possible policy proposal, I think it > deserves some discussion. > > The intent of the proposal 2018-01 ( > https://www.ripe.net/participate/policies/proposals/2018-01), was to > align the IPv4 and IPv6 policies in the matter of an LIR vs organization. > > We must remind that the allocation/assignment of resources is based on > justified need. And yes, we have a lot of IPv6 space, but it is really > justified and the same organization, having different LIRs, can use it as a > trick for stockpiling if there is not such justified need? > > In IPv4 this is not "a problem" because we don't have more space. Well ... > not exactly true ... some organizations could have used "the trick" to get > more IPv4 space by creating multiple LIRs. > > In other regions, I think this is not a problem because the cost of the > membership is not per "LIR" (flat rate in RIPE NCC), but based on the size > of the allocation/assignment. So, because IPv6 is not a scarce resource, it > seems there is no incentive to pay more for getting more if you're not > really using it. > > However, in RIPE NCC, if you created several LIRs for getting more IPv4 > allocations, *even if you don't use/need it* you can get (and thus > stockpile) IPv6 *at no extra cost*. > > I clearly think this is not a good thing. > > It seems to me that the problem lies in section 5.1.1. Initial allocation > criteria, and exactly here: > b) have a plan for making sub-allocations to other organisations and/or > End Site assignments within two years. > > So, is the problem that "a plan" is not sufficient if it is not "verified" > and the "bad guys" know that the chances for having it verified are too > small? > > Do we need some text about "recovery if not announced and used" ? > > Other ideas? > > Remember that the problem is not only about scarcity. This extra space may > be used "intermittently" for bad or even criminal activities and we have a > responsibility on that as a community. > > Regards, > Jordi > @jordipalet > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20201028/e7828084/attachment.html>
- Previous message (by thread): [address-policy-wg] stockpiling IPv6
- Next message (by thread): [address-policy-wg] stockpiling IPv6
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]