ietf
[Top] [All Lists]

Re: multihoming (was Re: draft-ietf-nat-protocol-complications-02.txt)

2000-04-25 17:30:03
At 1:11 PM -0700 4/25/00, Paul Francis wrote:
For me, your statement certainly reinforces the idea that multihoming in
IPv6 is indeed very difficult.

More accurately: multihoming in IP (any version) is indeed very difficult.
The problems are a fundamental consequence of having to do hierarchical
addressing and routing.  IPv6 is no worse than IPv4 in this regard, and
there are some features of IPv6 that might actually make make it better
(e.g., host support for multiple addresses on a single interface).

I read your statement as follows:

   IPv6 does not solve the multihoming problem.  Instead, it tries
   to minimize the damage by:
   
   1. discouraging the use of multihoming, primarily may making
   multihomed customers pay more for it.
   2. forcing paths to multihomed sites to be less efficient (at
   least for all but one of the ISP connection points) and or,
   3. limiting the regions of the internet for which multihoming
   is effective for a given customer.

Is this an accurate representation?

Not at all.  Try this:

    IPv4 has one, problematical solution to the site multihoming problem:
    advertise the site's prefix globally (or, at least, beyond more than
    a single ISP's domain).  This has obvious scaling problems as a
    solution to multihoming a very large number of sites (e.g., millions
    of households, as in Sean's example).

    People have accused IPv6 of lacking that one (non-scalable) solution
    to multihoming, based on a misunderstanding of the IPv6 address
    architecture.  That accusation is false, and nothing in IPv6 prevents
    the use of the same, lousy multihoming solution we have today for IPv4.

    IPv6 includes support for *additional* potential solutions to multihoming
    in which, rather than a site having a single prefix advertised globally,
    the site has multiple, aggregatable prefixes, and something more
    intelligent is done in the site's border routers and/or the the end
    hosts.  This is work-in-progress, and is likely to produce solutions
    with a different (but, we hope, acceptable in many contexts) set of
    shortcomings.

Steve



<Prev in Thread] Current Thread [Next in Thread>