nanog mailing list archives

Re: minimum IPv6 announcement size


From: joel jaeggli <joelja () bogus com>
Date: Fri, 27 Sep 2013 11:02:09 -0700


On Sep 27, 2013, at 10:04 AM, Randy Carpenter <rcarpen () network1 net> wrote:


There is no bit length which allocations of /20's and larger won't
quickly exhaust. It's not about the number of bits, it's about how we
choose to use them.

Regards,
Bill Herrin

True, but how many orgs do we expect to fall into that category? If the majority are getting /32, and only a handful 
are getting /24 or larger, can we assume that the average is going to be ~/28 ? If that is so, then out of the 
current /3, we can support over 30,000,000 entities. Actually, I would think the average is much closer to /32, since 
there are several orders of magnitude more orgs with /32 than /20 or smaller. Assuming /32 would be 500 million out 
of the /3. So somewhere between 30 and 500 million orgs.

How many ISPs do we expect to be able to support? Also, consider that there are 7 more /3s that could be allocated in 
the future.

As has been said, routing slots in the DFZ get to be problematic much sooner than address runout. Most current 
routers support ~1 million IPv6 routes. I think it would be reasonable to assume that that number could grow by an 
order of magnitude or 2, but I don't thin we'll see a billion or more routes in the lifetime of IPv6. Therefore, I 
don't see any reason to artificially inflate the routing table by conserving, and then making orgs come back for 
additional allocations.

In ipv4 there are 482319 routes and 45235 ASNs in the DFZ this week, of that 18619 ~40% announce only one prefix. given 
the distribution of prefix counts across ASNs it's quite reasonable  to conclude that the consumption of routing table 
slots is not primarly a property of the number of participants but rather in the hands of a smaller number of large 
participants many of whom are in this room.

-Randy


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Current thread: