[AusNOG] Final /8 allocated to APNIC from IANA (103/8)

[Matthew Moyle-Croft]

On 04/02/2011, at 10:38 AM, Damien Morris wrote:

On 4/02/11 11:02 AM, "Luke Iggleden" <luke at sisgroup.com.au<mailto:luke at sisgroup.com.au>> wrote:

Plenty of v6 space though guys..

340 undecillion, 282 decillion, 366 nonillion, 920 octillion, 938
septillion, 463 sextillion, 463 quintillion, 374 quadrillion, 607
trillion, 431 billion, 768 million, 211 thousand and 456


How many useable

Well, how many allocatable really.

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) (http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml).

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.

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.

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).

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.

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.

(Waits for the howling that comes from saying heretical things, whilst whistling "history never repeats, I tell myself before I goto sleep").

MMC

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20110204/90a05054/attachment.html>