The Cidr Report

Fred Baker (fred) fred at cisco.com
Wed Apr 30 21:32:27 UTC 2014


On Apr 26, 2014, at 12:19 PM, Deepak Jain <deepak at ai.net> wrote:

> Does anyone have doomsday plots of IPv6 prefixes? We are already at something like 20,000 prefixes there, and a surprising number of deaggregates (like /64s) in the global table. IIRC, a bunch of platforms will fall over at 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack).

A /64 deaggregte only makes it through because folks let it; there’s something to be said for filters. That said, one might generally expect every AS (there are about 60K or them, I gather) to have one prefix, and if it deaggregates, it might be reasonable to expect it to multiply by four. RIR online records suggest that someone that asks for additional addresses beyond their /32 is told to shorten the existing prefix, not allocated a new one - the same prefix becomes a /31 or whatever. The reason we have 500K+ IPv4 prefixes is because we hand them out in dribbles, and there is no correlation between the one you received last week and the one you receive today.

Geoff’s slides are interesting in part because of their observations regarding deaggregates. If 1% of of all AS’s advertise over half of the deaggregates, that seems like a problem their neighbors can help with, and if not them, the neighbors' neighbors. It’s hard to imagine that a single Ethernet (a single /64) is so critical that the entire world needs a distinct route to it.

In any event, I would not approach this as a statistical issue, and say “well, IPv4 grew in a certain way, and IPv6 will do the same”. It can. But we have had the opportunity to think ahead and plan for the growth, and the RIR communities have been planning. It seems likely that, with a little care, IPv6 should do quite a bit better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140430/b0918600/attachment.sig>


More information about the NANOG mailing list