[address-policy-wg] 2015-03 New Policy Proposal (Assessment Criteria for IPv6 Initial Allocation Size)

On Mon, May 11, 2015 at 11:10 AM, Gert Doering <gert at space.net> wrote:
>
>
> Slightly off-track, but you made me curious.  Given the number of /29s and
> /32s available in FP001, and the potential numbers of LIRs in the future
> (like, things explode and we'll see 100.000 LIRs) - where do you see the
> problem with our allocation sizes?
>

It's the old argument about quadrillions upon quadrillions (and more), and
how it's setting up for possible future failure in a way that's going to be
impossible to reverse at a later point in time.

I do think it's too late to put the cat back in the bag, at least for large
parts of how IPv6 addressing is handled, but I also don't think we need to
compound failure with failure.

I think we should balance between "too big" (aka: FP001 fills up, and
> new LIRs won't be able to get what they need [or we start using FP010])
> and "too small" (aka: LIRs will have to squeeze inside, and resort to
> unwanted behaviour, like "give customers only a single /64" or even
> "single /128").
>

I'm not sure that this is undesirable behaviour.

If it's undesirable, it's because the entire system has been rigged to
create the situation where it is undesirable, and then that is used as an
excuse for what I consider excesses.


>
> I see "/32 as default, up to /29 if you ask" as very reasonable middle
> ground...


It is far more than reasonable, and even though someone can legitimately
claim that they are making a setup where they can _use_ the entire IPv6
address space themselves by creating some convoluted network segmenting
scheme, it doesn't mean it's reasonable to do so.

Sure, having a /32 or greater permits us to easily use hexadecimal notation
for 4-bit granularity network segmenting.

I remain unconvinced, though, that this is necessary, even with an internet
of things that's on the level of Karl Schroeder's Ventus.

The change in policy text doesn't do anything about the practical limit,
except leaving more up to the good minds at the NCC to consider this.

Ideally, I'd think that there should be a hard limit at /29, and that there
should be very good reasons – reasons that need to be taken as a policy
debate or something like that – to go beyond that size.

As Nick states, "I'd be interested to see a real life addressing plan which
needed more than this amount of bit space." I'd actually be interested to
see a real life addressing plan that needed a /32 bit address space, where
the need isn't constructed based on the mere possibility of getting that
space instead of merely e.g. a few hundre million times of the entire IPv4
space.
-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20150511/e5b2b569/attachment.html>