On Dec 4, 2013, at 12:43 , Brian Dickson <brian.peter.dickson@gmail.com> wrote:
On Wed, Dec 4, 2013 at 3:09 PM, Owen DeLong <owen@delong.com> wrote:
On Dec 4, 2013, at 10:21 , Brian Dickson <brian.peter.dickson@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.
Only if you feel the need to carry those global routes all the way down to your border devices (which is unlikely in the kind of residential scenario proposed).
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 think it is already too entrenched to change, but I guess time will tell. Since we are only talking about how we use the first 1/8th of the address space and we didn't even exhaust that in your particularly overblown example, I am unconcerned.
I can't believe I just called 2**64 small.
Well, it's smaller than 2^128. ;-) Owen