On 5-mrt-2006, at 5:48, Roland Dobbins wrote:
This fundamental misconception of the requirements of large enterprise customers should be an indicator to proponents of shim6, among others, that they do not have a good grasp of the day-to-day operational and business realities faced by large enterprises. This lack of understanding has led to such fundamental misconceptions as a belief that large enterprises can accept frequent renumbering within their organizations based upon changing business relationships with their SPs (they cannot, see RFC 4192 for some of the reasons why not)
Ok, let me show you a trick I learned recently. I'm going to agree with you (although like everything else, the "need" for stable addresses can be translated into money, at some point it makes sense to renumber), and tell you I have the solution that fixes all of this, doesn't cost any money, no new code, nothing. Then after this, you'll see that nobody replies to this message and we simply go on arguing about the relative evil of PI in IPv6 vs that of shim6. The solution is routing based on geography: give every city of ~ 250k people a /32, and give people who multihome in or near that city a / 48 out of that /32. Since such a /48 will be easy to get, the global routing table will fill up with these /48s relatively quickly, and at some point it will start to look attractive to filter some of them out in part of an AS. This can be done without trouble by adding a few /32 aggregates that point towards the part of the AS where the / 48s that are filtered here are still known. Since every AS still has all the /48s somewhere within the AS, this works without strange requirements such as free transit or interconnection in every city. So what do we need to get this off the ground? New allocation policies. As long as the number of geo PI prefixes is smaller than what comfortably fits inside routers that's all. If the global routing table continues to grow transit ASes will have to choose between buying more expensive routers or adding complexity by implementing geographic aggregation using BGP filters. Obviously strange ways of multihoming (towards ISPs on different continents, for instance) or strange ways of interconnecting (such as two European networks interconnecting in Chicago) aren't very compatible with geographic aggregation, but who cares about 10% exceptions as long as you can aggregate the other 90%. Enterprises will have to choose between individual geo /48s in every location or becoming their own ISP with a /32 and backhaul traffic between locations themselves.