* Jim Reid:
There's no reason to repeat the same mistakes with IPv6 allocation policy as we did with IPv4. Doling out lots of non-aggregatable IPv6 PI allocations will just give us a re-run of today's IPv4 routing table scalability horrors.
With IPv4, you can aggregate routes before installing them into the FIB (because only few of the routing decisions are semantically meaningful), at least if the CPU which computes the FIB is a bit more beefy than what is built into your smartphone. If your vendor still isn't doing that, it might make sense to consider switching vendors, or at least use it as a negotiating tool for getting better deals on upgrades. So IPv4 isn't that bad, even technically, if you think about it. But it turns out that the current IPv6 allocation practice prevents running with aggregated FIBs---there's a hole after each PA allocation. The hole is visible because you're expected to generated ICMP unreachables for packets target there, so you can't lump two PA prefixes together, even if they share the same next hop. This is yet another case of premature optimization gone wrong. IPv6 history is full of well-meaning optimization attempts, but curiously few actually are an improvement over IPv4, and some are downright harmful (like the header layout "for optimized forwarding"). -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99