<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 13, 2010, at 7:43 AM, William Herrin wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Sun, Oct 10, 2010 at 12:08 PM, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br><blockquote type="cite">On Oct 10, 2010, at 7:09 AM, William Herrin wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">7 billion people in the world, each of which consumes Internet<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">service, so as a lower bound we'll need 9 bits worth of 20M-equivalent<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ISPs to serve them.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">4,200,000,000 / 20,000,000 = 210 = 8 bits worth of 20M-equivalent<br></blockquote><blockquote type="cite">ISPs. However, it won't actually work out that way. The vast majority<br></blockquote><blockquote type="cite">of ISPs will be much smaller and there will be many more of them.<br></blockquote><br>Okay. 8 bits, 9 bits. The key result from all the math is this:<br><br>Between an austere deployment of IPv6 (/60 end users, cramped routing,<br>etc) and a deployment of IPv6 that will consume the entire address<br>space prior to the retirement of IPv4, we have roughly 22 bits, not<br>the 96 bits that one might naively expect with an expansion from 32 to<br>128 bits.<br><br></div></blockquote>Somewhere between 32 and 40 by my count, but, anyway...</div><div><br><blockquote type="cite"><div>Responsible management demands that we treat some portion of that 22<br>bits as a consumption suppressor so that we don't quickly run out of<br>IPv6 addresses. Whatever is left over, be it 4 bits, 20, or anything<br>in between, that's the number of bits we can actually afford to use<br>for nice-to-haves, like a larger standard end-user assignment than /60<br>(/56 or /48), sparse assignment and so on.<br><br></div></blockquote>Hence the /3 and the reservation of 7/8ths of the address space.</div><div>The IETF already put the consumption suppressor stake in the ground there.</div><div>I see no reason to move it.</div><div><br><blockquote type="cite"><div><br><blockquote type="cite"><blockquote type="cite">: how should we divvy up the 22 bits<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">between IPv4's consumption rate and IPv6's minimum needful consumption<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">rate? How many bits of convenience and how many bits of responsibly<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">slow consumption?<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite">_IF_ I understand what you mean by these terms correctly, then, yes,<br></blockquote><blockquote type="cite">I think an 8/14 ratio isn't such a bad ratio<br></blockquote><br>It sounds to me like you do understand what I mean.<br><br>8 bits of conservation worries me. We badly underestimated at the<br>start of IPv4. I'd be more comfortable starting with a more<br>conservative number (like 12 or 16) and then working down to 8 bits of<br>conservation after we gain a decade or two of experience.<br><br></div></blockquote>Yeah, I think that's pretty absurd. Conserving 255/256ths of the address</div><div>space is somewhat absurd to begin with, but, hey, why not... Plenty of</div><div>room in the 1/256th we're talking about, so, OK... Let's try that.</div><div><br></div><div>Conserving 4095/4096ths of the address space, well, that's getting</div><div>ridiculous on its face. Especially in light of the need for ridiculous</div><div>wastes of IPv6 like 6rd in order to get IPv6 deployed because the</div><div>vendors of last mile technology managed to get caught with their</div><div>pants down by an event that they had more than a decade of warning</div><div>was coming.</div><div><br></div><div>I agree it's tragic and wasteful. However, I think it is better to deploy</div><div>with 6rd than to fail to deploy and end up with LSN more widely</div><div>deployed.</div><div><br></div><div><blockquote type="cite"><div>On the other hand, if the current address consumption rate holds at<br>what eyeballs to me vaguely like 0.6(n^2), 8 bits of conservation<br>should buy us around 115 years. If Geoff is lurking, I'm sure he can<br>provide better information assuming completion of the IPv6 transition<br>with IPv6 consumption at 1/256th of IPv4's current consumption and the<br>same consumption growth rate exhibited over the last 15 years in IPv4.<br><br></div></blockquote>A very good argument for 8 bits or less...</div><div><br><blockquote type="cite"><div>Anyway, let's run with 8 bits and see what it implies.<br><br>8 bits means that the maximum allocation we can allow a single<br>organization to seek both initially and due to prior consumption is<br>/20. The largest holding we can allow an affiliated set of<br>organizations (including merged and acquired ISPs) totals /16. The<br>4-bit difference comes from that hold-against-development set I talked<br>about. Larger allocations than this, regardless of cause, are likely<br>to see us deplete the IPv6 free pool faster than the 8-bits<br>conservation target we've set.<br><br></div></blockquote>OK.</div><div><br><blockquote type="cite"><div>8 bits also means you have only 14 bits left for the nice-to-haves. If<br>you spend 12 of those bits bringing the downstream end-user assignment<br>from the austere /60 to your preferred /48, you'll have only 2 bits<br>left. That doesn't give you much flexibility with your routing. Are<br>you sure you wouldn't rather put 4 of your bits to bring the<br>assignment up to /56 and use the remaining 10 to do smarter things<br>with your routing hierarchies? 256 LANs is a lot of LANs for all but<br>the largest customers.<br><br></div></blockquote>And here's where you run off the rails again by miscounting the bits.</div><div><br></div><div>Let's look at the reality...</div><div><br></div><div>Tiny ISPs with fewer than 30,000 end sites served fit fine in a /32.</div><div>Probably about 15% of total ISPs.</div><div>Small to medium ISPs with between 30,000 and 500,000 end</div><div>sites served warrant a /28. Probably about 50% of total ISPs.</div><div>Large ISPs with between 500,000 and 12,000,000 end</div><div>sites served (probably about 30% or more of total ISPs) warrant a /28.</div><div>Extraordinarily large ISPs with more more than 12,000,000 end</div><div>sites served would get a /20 or in extreme cases, maybe a /16.</div><div>I'll divide these up as 4% get a /20 and 1% a /16 for purposes</div><div>of discussion. I suspect the real numbers are more like 4.99% and</div><div>0.01%.</div><div><br></div><div>Assuming for the moment that there are roughly 30,000 ISPs</div><div>on the planet, those percentages work out as follows:</div><div>Quan<span class="Apple-tab-span" style="white-space:pre"> </span>Pfx<span class="Apple-tab-span" style="white-space:pre"> </span>/32 equiv.</div><div>4,500<span class="Apple-tab-span" style="white-space:pre"> </span>/32<span class="Apple-tab-span" style="white-space:pre"> </span>4,500</div><div>15,000<span class="Apple-tab-span" style="white-space:pre"> </span>/28<span class="Apple-tab-span" style="white-space:pre"> </span>240,000</div><div>9,000<span class="Apple-tab-span" style="white-space:pre"> </span>/24<span class="Apple-tab-span" style="white-space:pre"> </span>2,304,000</div><div>1,200<span class="Apple-tab-span" style="white-space:pre"> </span>/20<span class="Apple-tab-span" style="white-space:pre"> </span>36,864,000</div><div>300<span class="Apple-tab-span" style="white-space:pre"> </span>/16<span class="Apple-tab-span" style="white-space:pre"> </span>19,660,000</div><div><br></div><div>Total<span class="Apple-tab-span" style="white-space:pre"> </span>59,072,500 /32s</div><div><br></div><div>This would mean that we consume a total of 3.5 /16s to</div><div>number the entire existing internet according to my</div><div>suggested way of numbering things.</div><div><br></div><div>I'm willing to set aside a few other /16s for 6rd to be deployed</div><div>temporarily (~5-10 years, hopefully), so long as they are done</div><div>in such a way that a community decision to deprecate them and</div><div>reclaim them is enforceable. (specific prefixes which can be</div><div>filtered without harming native deployments).</div><div><br></div><div>Since we've already given each RIR a /12 to start off with and</div><div>we still have 506 /12s left in the /3 from which we are</div><div>allocating, I think we're OK.</div><div><br></div><div>Owen</div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div></blockquote></div><br></body></html>