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 <rmcintosh@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 <LarrySheldon@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)