[address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation

* 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 at 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