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

On 16 Feb 2011, at 19:08, Igor Ybema wrote:

> I'm also trying to receive IPv6 PI for a webhosting customer of us  
> which seems to be a big problem.

Well perhaps you could explain to us why you or your customer feel  
they need IPv6 PI space for webhosting. I'm struggling to see what the  
justification might be for any sort of PI space for that.

> I do not understand why everyone claims that 'the routing table  
> growth' is
> the reason not to allow too much IPv6 PI.

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. Except with much longer prefixes => burning  
even more router memory and CPU.

IPv6 gives us the potential to waste more space on PI vanity projects.  
That doesn't mean we should do so just because we can. Just think of  
the number of edge devices that are likely to get IPv6 addresses and  
have suppliers/vendors managing those edge address assignments:  
consumer electronics gadgets, RFID tags, phones, utility meters,  
lightbulbs, sensor networks, etc, etc. If these suppliers/vendors head  
down the PI path, life will get unpleasant. Unless you are a Cisco,  
Juniper or semiconductor shareholder.

We now know a great deal more about how address policies affect route  
deaggregation than we did back in the good old days. Since IPv6  
allocation policy is essentially starting from a blank sheet of paper,  
it shouldn't be encumbered with all the cruft and bad ideas that IPv4  
policies picked up along the path to their eventual oblivion. This  
does of course mean that we can (and probably will) make new mistakes  
with IPv6 address allocation. It should not mean repeating the earlier  
ones.

Please also bear in mind that there will be even more IPv4  
deaggregation as the run-out starts to bite. So let's not make the  
router problems even worse by facilitating an explosion in the IPv6  
routing table as that other problem gathers momentum.

> Those currently having IPv4 PI would of course require IPv6 PI  
> because they
> still want to be indepentent. If they need to be a LIR to get IPv6  
> PA the
> problem is not solved for the routing-table issue. A prefix is still  
> entered
> into the same global routing-table.

This is true but misses the point Igor. Consider an LIR which doles  
out a /80 (say) to each of its customers who buys its web hosting  
services. These prefixes can be aggregated behind a single /64 (or  
whatever) => 1 routing table entry. If each of those customers got its  
own IPv6 PI space (why?), that's N routing table entries, all with  
longer prefixes, etc, etc.

I'm unconvinced that "wanting to be independent" (of what?) for  
someone who's only needing some web hosting is a justification for PI  
space.