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.