ietf
[Top] [All Lists]

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

2000-04-25 14:40:03
 
 Sean Doran <smd(_at_)ebone(_dot_)net> writes:
 
 > Unfortunately, IPv6's current addressing architecture makes it very
 > difficult to do this sort of traditional multihoming if one is not
 > a TLA.
 
 This is not true. IPv6's TLA scheme has as its primary goal placing an
 upper bound on the number of routing prefixes that are needed in the
 
 That doesn't mean that all or even any of these routes will be
 optimal. An individual provider, may, maintain longer prefixes for
 selected destinations in order to provide better contectivity, say, to
 those willing to pay. Thus, traditional multihoming is still quite
 possible, assuming the various ISPs that need to handle the routes
 agree to do so. But the goal is to make such routes exceptions that
 are value-add rather than are a fundamental requirement in order to
 insure global reachability for all.
 

Sean said that traditional multihoming would be "very difficult".

You replied that "This is not true" (which I take to mean
that multihoming is not very difficult), and then go on to describe
something that sounds very difficult to me (maintain longer prefixes,
make multihomed customers pay for it, get the ISPs to agree to
handle such longer prefixes).  You say that "multihoming is still
quite posible", but nobody said that it was impossible, just
difficult.  For me, your statement certainly reinforces the idea
that multihoming in IPv6 is indeed very difficult.

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?

PF



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