<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 11, 2015 at 11:10 AM, Gert Doering <span dir="ltr"><<a href="mailto:gert@space.net" target="_blank">gert@space.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>Slightly off-track, but you made me curious.  Given the number of /29s and<br>
/32s available in FP001, and the potential numbers of LIRs in the future<br>
(like, things explode and we'll see 100.000 LIRs) - where do you see the<br>
problem with our allocation sizes?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we should balance between "too big" (aka: FP001 fills up, and<br>
new LIRs won't be able to get what they need [or we start using FP010])<br>
and "too small" (aka: LIRs will have to squeeze inside, and resort to<br>
unwanted behaviour, like "give customers only a single /64" or even<br>
"single /128").<br></blockquote><div><br></div><div>I'm not sure that this is undesirable behaviour.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I see "/32 as default, up to /29 if you ask" as very reasonable middle<br>
ground...</blockquote></div><div><br></div><div>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.</div><div><br></div><div>Sure, having a /32 or greater permits us to easily use hexadecimal notation for 4-bit granularity network segmenting.</div><div><br></div><div>I remain unconvinced, though, that this is necessary, even with an internet of things that's on the level of Karl Schroeder's Ventus.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div>-- <br><div class="gmail_signature">Jan</div>
</div></div>