[address-policy-wg] stockpiling IPv6

Hi,

While I will admit it's a bit odd to allocate that much v6 space to a
single entity, I don't see how this is going to cause issues based on what
is currently happening, like this is not happening at scale.

Sure there might be a /21 (256x /29) of IPv6 space assigned to LIRs who
already had a /29. but there are many large ISPs who alone have more space
than this. Telia has a /20, China Telecom has a /16.

Additionally there is no real incentive to request multiple /29s other than
very rare cases. unless LIRs requesting like 16x /29s are a common
occurrence, this is a non issue imo.

disclaimer: I do have 3x /29 for a reason that may seem like a waste to
some people and my specific issue could probably be solved by RIPE allowing
me to split my /29 into /32s.

-Cynthia

On Wed, 28 Oct 2020, 13:05 JORDI PALET MARTINEZ via address-policy-wg, <
address-policy-wg at ripe.net> wrote:

> 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/5eede270/attachment.html>