On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong <o...@delong.com> wrote: > > On Dec 4, 2013, at 10:21 , Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > Second of all, what would make much more sense in your scenario is > to aggregate at one or two of those levels. I'd expect probably the POP > and the Border device levels most likely, so what you're really looking > at is 5000*100 = 500,000 /48s per border. To make this even, we'll > round that up to 524,288 (2^19) and actually to make life easy, let's > take that to a nibble boundary (2^20) 1,048,576, which gives us a > /28 per Border Device. > > > Except that we have a hard limit of 1M total, which after a few 100K from the global routing tables (IPv4+IPv6), this 500,000 looks pretty dicey.
> > > And root of the problem was brought into existence by the insistence that > > every network (LAN) must be a /64. > > Not really. The original plan was for everything to be 64 bits, so by > adding > another 64 bits and making every network a /64, we're actually better off > than we would have been if we'd just gone to 64 bit addresses in toto. > > Thanks for playing. > > Owen > > Understand, I am not saying anyone got it wrong, but rather, that there is a risk associated with continuing forever to use a /64 fixed LAN size. Yes, we are better than we were, but the point I'm making is, if push comes to shove, that the /64 is a small thing to sacrifice (at very small incremental cost, SEND + AUTOCONF modifications). I can't believe I just called 2**64 small. Brian
