Requirements [was Re: Transport level multihoming]

[Brian E Carpenter <brian@hursley.ibm.com>]

Ran Atkinson wrote:
> 
> At 13:33 03/04/01, Brian E Carpenter wrote:
> >I'm against making that too absolute. It is a bit more subtle:
> >
> >  A multihomed site must be able to operate legacy applications
> >  unchanged. However, it may be desirable for the multihoming
> >  system to offer hints or even controls to applications able
> >  to use them, by means of a multihoming API.
> 
>         I'd edit that to clarify what is meant by "...to
> operate...unchanged".  That phrase could mean operate legacy
> apps without multihoming capability without change xor it could
> mean operate legacy apps with multihoming capability unchanged.

Sure. I meant that the applications theselves should be unchanged. 
Some of them will be IPv4 applications running over Bump-in-the-Stack
or Bump-in-the-API, and others will have been tweaked to use the new
Socket API but otherwise untouched. For quite a few years most apps
will be in one of those two classes.
> 
> >A more basic question - are we able to *require* changes in the
> >host IPv6 stack in support of multihoming?
> 
>         If not, then we close the door on a large class
> of potential solutions.  In particular, the TCP/UDP
> Protocol Control Blocks currently bind the IP addresses
> on both sides tightly into each session.  The sort of approach
> that GSE outlined would want to bind the PCBs to some
> identifier that was not the IP address used for packet
> forwarding.

That's fair comment, but remember that we have legacy IPv6 stacks already.
We certainly can't assume that host IPv6 stacks will all get upgraded
rapidly to cover such changes - i.e. hosts must not lose connectivity if 
they are not upgraded for multihoming, even if they don't get full benefit
from the multihoming.

  Brian