Yeah, that presentation describes classful allocation, which isn't what we're actually doing with v6 (because that would be one of the mistakes of v4 that we're avoiding). It also seems to think that you can identify individual devices from the IP, which isn't really true. IPs encode a node's current network location, not its identity. (Don't get confused by SLAAC; yes, it inserts the MAC into the IP address, but that's just as a convenient way of generating a unique IP. There's no requirement to use the MAC there, and v6 doesn't do anything special with it -- those are just opaque bits as far as v6 is concerned.)
There's no way to send a packet to a given MAC, or to look up the rest of the IP from just the MAC, or anything like that. The last page of the presentation makes it clear that he's expecting that, but it's not something that v6 can do. There are protocols that can handle it (LISP?) but you could just as well have the devices phone home to a central server with their UUID. Neither of those would require inserting the UUID into the IP. Slide 19 sorta comes to that conclusion if you read between the lines a bit.
That presentation is from 2005 or earlier so you could maybe excuse it as being dated, but if so then you can't use it as a useful argument in a discussion today. All it's really arguing is that classful allocation of networks won't fit into 64 bits, which is true but irrelevant since we're not doing classful allocation.
A /48 is way too big for a typical home user even if we start having toasters, cookers, fridge's all with internet connectivity.
Good! Our allocations should be way too big, rather than way too small. The only question is whether we have enough address space to cover them.
There are 5000 /48s available per person on the planet, so unless you think that each person is going to run thousands of separate networks then we should be fine with that. If you want to talk /56s there are ~330 million per person, which is definitely in "enough" territory. And even if that's somehow wrong, both of these figures are from just 2000::/3, and there's another five unused /3s so we could start all over again in one of those using tighter allocation policies if needed.
In summary: /48s should be fine, /56s certainly will be, and there's no argument whatsoever for going down to /64s.
similar mistakes to ipv4 are been made in that the current policy is to supply ipv6 at very generous levels to organisations
The allocations we're doing in v6 are nothing like the ones we've done in v4. The "standard" ISP allocation is a /32, which consumes the same fraction of the v6 space that a single IP does in v4. Would you consider a single IP, for an ISP with tens of thousands of large end-user networks, to be "very generous" in v4?
If you can find me some /8s issued to individual companies, or /16s issued to users that could fit into a /48, then you'd definitely have a point, but we're not making allocations like that.
