- Previous message: Joe Abley: "Re: shim6 @ NANOG"
- In reply to: Roland Dobbins: "Re: shim6 @ NANOG"
- Next in thread: Iljitsch van Beijnum: "Re: shim6 @ NANOG"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Iljitsch van Beijnum (no email)
Date: Sun Mar 05 2006 - 09:41:50 EST
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.
|
|
|