Re: Requirements [was Re: Transport level multihoming]

[xxvaf <xxvaf@mfnx.net>]

> > >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.

IMHO, the number of such "legacy ipv6 stacks" is insignificant compared to
the opportunity to do multihoming right. Especially if, as some now believe,
getting this right means the difference between allowing the routing system
to scale or watching it stop working during the next year or two. One would
also imagine that the users of the legacy systems are also (very) early
adopters who must know that early implementations are subject to change.

As I believe Noel once said, there is at most one chance to make substantial
change to the Internet network and transport protocols. One would hope that
the changes to be made will provide more benefit than just expanding the
locator field from 32 to 128 bits.

My brief persual of SCTP suggests that it could have some promise. Two
questions for someone with more knowledge of its details:

    - Has any work been done to port existing protocols and applications
      (HTTP, SMTP, FTP, TELNET, SSH, etc.) to SCTP? If not, how difficult
      would it be to provide a TCP-compatible API? What, if any, approach
      might be taken for UDP-based applications, such as DNS?

    - My reading of SCTP suggests that it only supports multiple address
      negotiation at session establishment. This would seem to make it
      difficult for it to deal with address renumbering events, which is
      kind of unfortunate. Has any thought been given to this?

Geoff's presentation indicates that multi-homing and consequent traffic
engineering tricks (i.e. selective leaking of more-specifics) represents the
biggest growth problem facing the routing system today. If multhoming at 
the transport layer can be made to work well, it would seem to hold some
potential as a solution. Can transport-layer multihoming solve all of the
requirements so far listed in the multi6 draft? I dunno - an analsys of
that might be interesting...

	--Vince