<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 11, 2015 at 7:19 PM, Sascha Luck [ml] <span dir="ltr"><<a href="mailto:apwg@c4inet.net" target="_blank">apwg@c4inet.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, May 11, 2015 at 03:58:46PM +0200, Jan Ingvoldstad wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As Nick states, "I'd be interested to see a real life addressing plan which<br>
needed more than this amount of bit space." I'd actually be interested to<br>
see a real life addressing plan that needed a /32 bit address space, where<br>
the need isn't constructed based on the mere possibility of getting that<br>
space instead of merely e.g. a few hundre million times of the entire IPv4<br>
space.<br>
</blockquote>
<br></span>
The way I read the proposal, it is not about assignment sizes but<br>
about a "aggregation" vs "conservation" conflict. The proponents have, AIUI, a problem where they might not fully<br>
assign a /32 or /29 allocation but have different routing<br>
policies for parts of their network, which cannot be satisfied<br>
without violating s3.4 of ripe-641. </blockquote></div><br clear="all"><div>Apparently, my point was not very reader friendly, so I'll try again:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Also, as I said, and obviously have to repeat for some people: that cat is out of the bag. It is what it is.</div><div><br></div><div>But there is no need to compound this design failure.</div><div>-- </div><div class="gmail_signature">Jan</div>
</div></div>