On Mon, May 11, 2015 at 7:19 PM, Sascha Luck [ml] <apwg@c4inet.net> wrote:

On Mon, May 11, 2015 at 03:58:46PM +0200, Jan Ingvoldstad wrote:

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.

The way I read the proposal, it is not about assignment sizes but
about a "aggregation" vs "conservation" conflict. The proponents have, AIUI, a problem where they might not fully
assign a /32 or /29 allocation but have different routing
policies for parts of their network, which cannot be satisfied
without violating s3.4 of ripe-641.

Apparently, my point was not very reader friendly, so I'll try again:

Routing-wise, someone with 64 billion billion billion addresses, have about 16 billion billion ways to route the entire IPv4 internet, within the address space constraints of a /32 allocation.

Even if we pretend that it's an extremely useful and necessary thing to have a /64 per end user, so that each end user can enumerate and route the entire EUI-64 space, a /32 is still the same as the entire IPv4 space.

That there is a "need" for allocating as much as a /32 in the first place is a design failure in how the addressing segmentation has been handled, in my opinion. It's the IPv4 /8 allocation mistake all over again.

Also, as I said, and obviously have to repeat for some people: that cat is out of the bag. It is what it is.

But there is no need to compound this design failure.

Jan