[6bone] multiple address handling

[Tim Chown]

On Sun, Oct 20, 2002 at 05:19:05PM +0200, Arien Vijn wrote:
> 
> On 20-10-2002 15:42PM, "itojun@iijlab.net" <itojun@iijlab.net> wrote:
> 
> >> Of course part of the problem is the lack of progress of the multi6 WG,
> >> albeit a non-trivial problem to be working on :)   The "classic" IPv6
> >> solution for our university is to take two /48's from different providers,
> >> and for all clients to have two global addresses, but the client-side
> >> support for handling the multiple addressing is yet to be resolved.
> > 
> > curious: where do you see problems in multiple address handling?
> > i don't really see any, except the lack of ability to switching
> > address pair for TCP (maybe we should use SCTP?).
> 
> This is the major problem. Increased reliability is certainly a factor why
> one wants to be multi homed.

This was the major "problem" I had in mind, yes.  The issues include:

(1) Configuration of internal site router infrastructure with new prefixes
    as new external links are administratively added.

(2) Removal of configuration on site infrastructure for prefixes for links 
    that get administratively removed (e.g. a change of main provider, both
    prefixes are used for a rollover period).

(3) Deprecation for links that are unavailable.  The internal site routing
    would presumably remain, but the end hosts should be signalled that the
    prefix is deprecated.  A temporary case of (2).

(4) Renewed availability of a temporarily deprecated prefix.

[Some may say (3) and (4) are the same as (1) and (2)]

(5) Source host src/dst address selection.  There has been good work on this.
    I'm not clear on how this ties in to default router selection with router 
    precedences, or the (relatively) new load balancing proposal.

(6) Sustaining TCP connection when (2) or (3) occur.  This is something of
    a void that SCTP could fill, or maybe some Mobility-like solution.  Of
    course it only matters for some applications, but it has to be solved.

In theory IPv6 router renumber handles cases (1) and (2).  Cases (3) and (4)
could also use router renumbering and RAs combined.

It's (6) that's the fuzzy area.

I think the standard renumbering scenario that Christian Huitema(?) presented 
a while ago assumed orderly renumbering with provider change, rather than
sudden link loss.

Then of course there's the side issues of DNS, firewalls, etc for new
prefixes introduced.  

I'd be interested in seeing a case study of a site that has all the above
working and 3 or more layers of internal routers (which we have), not
just a single multihomed router.   I had assumed multi6 was stalled because
this hadn't been shown, not because it has :)

Tim