The original plan was to go from 32 to 64 bits total. The additional 64 bits were added purely for the sake of EUI-64 based addressing, and really, 64 bits of network number is way more than enough.
The /64 a are not what justify the larger blocks. That's IPv4 think. In IPv6, it is far better to think about the number of sinners without regard to counting hosts. The /48 per site is justified because it is almost inconceivable that a single site would ever need more than 65536 subnets. The /32 is a minimum reasonable allocation for an ISP to balance the tradeoff between routing table entries and consumption. Most estimates say that the vast majority of significant providers will end up using a /28 with some outliers on both sides. Many smaller providers will end up with /32 and a few medium to large ones will get /24 or even /20. A minute (probably less than 20 world wide) number might get /16s. Absent some novel (and IMHO I'll-advised) approach to semantic overloading, we will have plenty of address space to number the internet for many many years. Owen > On Oct 1, 2013, at 12:11, Ryan McIntosh <rmcint...@nitemare.net> wrote: > > I'd love to be able to turn the microwave and oven on with my phone.. > maybe ten years from now lol.. > > In all seriousness though (and after skimming some of the other > responses), I absolutely understand the ideals and needs amongst > conserving memory on our routers for the sake of the future of bgp and > internal routing. The problem I described has nothing to do with that > however, I was mearly pointing out the fact that the basis of the > larger allocations are based upon the fact we're handing over /64's to > each vlan/point to point/lan/etc that we're turning up. In practice, I > understand, a /64 means that 64 bits can handle a unique ip for every > host without having to worry about numbering them, but how many hosts > do we truly think will be sitting on one network? Surely not a /64's > worth, that alone would cause havoc on a neighbor table's maximum > memory limit. Maybe I'm missing the connection here, but I still don't > see how a /64 is justified for each individual user/host/server/etc > sitting on the edge of the internet that's getting ip's from an > upstream provider (not arin/ripe/etc). > > It's those smaller blocks that justify handing over larger ones, which > I do understand there's plenty of, but how long are we going to patch > the same problem and not try to fix it right? > > Ryan > >> On Mon, Sep 30, 2013 at 8:37 PM, Larry Sheldon <larryshel...@cox.net> wrote: >>> On 9/27/2013 1:10 AM, Ryan McIntosh wrote: >>> >>> I don't respond to many of these threads but I have to say I've >>> contested this one too only to have to beaten into my head that a /64 >>> is "appropriate".. it still hasn't stuck, but unfortunately rfc's for >>> other protocols depend on the blocks to now be a /64.. >>> >>> It's a waste, even if we're "planning for the future", no one house >>> needs a /64 sitting on their lan.. or at least none I can sensibly >>> think of o_O. >> >> >> >> Are you accounting for connections to your refrigerator, water heater, >> razor, vibrator, and on down to list so the gubermint can tell they when you >> can use power for them? >> >> -- >> Requiescas in pace o email Two identifying characteristics >> of System Administrators: >> Ex turpi causa non oritur actio Infallibility, and the ability to >> learn from their mistakes. >> (Adapted from Stephen Pinker) >>