multihoming

[Joel Baker]

On Sun, Apr 28, 2002 at 07:00:47PM +0300, Pekka Savola wrote:
> On Sat, 27 Apr 2002, Bill Manning wrote:
> > % >> I was under the impression that IPv6 multihoming required an ASN?
> > % >It does indeed require one as the only way to be multihomed today in IPv6 is to be a xTLA.
> > % 
> > % 	depending on what you mean by "multihoming" and what kind of failure
> > % 	you want to cope with.
> > % 	yes, if you want to do currently-practiced provider-independent address/
> > % 	punching-hole routing info style multihoming, you need an ASN.
> > % 
> > % 	RFC3178 is working just fine for me without ASN or provider-independent
> > % 	address/punching hole (basically, you get two /48 prefixes from two
> > % 	upstream provider, and you can cope with link failure to upstream).
> > % 
> > % 	btw, i wonder why it is justified by people doing punching-hole style
> > % 	multihome, to taint/overload worldwide routing table for the benefit of
> > % 	a leaf site.  i guess we need a better routing protocol, or something.
> > % 
> > % itojun
> > 
> > 	tainting/overloading the routing table for IPv6 is 
> > 	a non-issue at this point in time.  [...]
> 
> Sure, but stopping an avalanche is not an easy job.  We haven't managed to
> kill irresponsible multihoming etc. with IPv4, so if we let go of these
> requirements, we'll probably never be able to prevent the future problems.
> 
> When IPv6 routing table is at e.g. 5,000 entries, it may be too late to
> set any effective policies.  We're seeing this now with IPv4 /24's etc.

Once again... you cannot solve a social/business problem with technical
limitations, effectively. People who have motivation will always find new
and creative ways to get around them.

People want multihoming, enough to pay for it - and pay well. This means
that it WILL happen, whether you like it or not. You can manage to do it
via IPv4-style ASN+1 netblock announcements (leading to fractured routing
tables, but conservation of address space) or to IPv6/hierarchial style
route-via-xTLA methods, where you have easy to manage routing tables, but
blow lots of address space (because companies will have 1 block from each
of their upstreams). The latter also requires protocols that support this
kind of split natively and sanely, for long-term availability.

I'd say something about research vs. production networks here, but I can't
find any way to make it come out right. Suffice to say, most of us aren't
working for DARPA at this point.
-- 
***************************************************************************
Joel Baker                           System Administrator - lightbearer.com
lucifer@lightbearer.com              http://users.lightbearer.com/lucifer/