<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br>
<div>
<div>On 04/02/2011, at 10:38 AM, Damien Morris wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div>On 4/02/11 11:02 AM, "Luke Iggleden" <<a href="mailto:luke@sisgroup.com.au">luke@sisgroup.com.au</a>> wrote:<br>
<br>
<blockquote type="cite">Plenty of v6 space though guys..<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938<br>
</blockquote>
<blockquote type="cite">septillion, 463 sextillion, 463 quintillion, 374 quadrillion, 607<br>
</blockquote>
<blockquote type="cite">trillion, 431 billion, 768 million, 211 thousand and 456<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<br>
How many useable<br>
</div>
</blockquote>
</div>
<br>
<div>Well, how many allocatable really. </div>
<div><br>
</div>
<div>Once you start going /64 for each LAN segment, /48 for each end site, the first 4 nibbles for IANA, minimum allocation for an ISP like org is a /32, then you've carved it up quite a lot already. Then you've got IETF "reserving space" (oh no, not Class
E again) (<a href="http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml">http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml</a>).</div>
<div><br>
</div>
<div>In the name of keeping the IPv6 routing table small, a lot of large organisation are getting big chunks of space. This seems fine now (Class A seemed fine at one point), but maybe it's not so good long term.</div>
<div><br>
</div>
<div>US Mil has a /13. /20 and similar allocations (eg. Softbank BB in Japan) aren't uncommon. A lot of places with /32s are going to find that, heck, it's quite hard to keep within a /32.</div>
<div><br>
</div>
<div>There's a proposal on sig-policy in APNIC to increase the allocations to ISPs. (Which I support as we've found a /32 doesn't work so well for us at the 250-300k customer kind of size).</div>
<div><br>
</div>
<div>I'm not saying we need to be obsessive as we've become with IPv4, however, we do need be mindful of the IPv4 experience that whilst it seems big and plentiful today, that maybe we could be a bit more careful now and let our children's children not have
to go through this again. </div>
<div><br>
</div>
<div>Some of the decisions are too late to turn around, but reducing the default end site size to /56 from /48 would give 8 bits back to being with.</div>
<div><br>
</div>
<div>(Waits for the howling that comes from saying heretical things, whilst whistling "history never repeats, I tell myself before I goto sleep").</div>
<div><br>
</div>
<div>MMC</div>
<div><br>
</div>
</body>
</html>