On Mon, May 11, 2015 at 7:19 PM, Sascha Luck [ml] <[email protected]> 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
