On Mon, May 11, 2015 at 11:10 AM, Gert Doering <gert@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