Whilst it is probably undesirable to *require* (b) 'maintaining existing upper
layer communication sessions', mechanisms have already been proposed in
Mobile IP for v6 which will
- allow seamless maintenance of upper layer connections, and
- conceal the change of IP layer address(es) from the transport layer
thus requiring no changes to the API or applications that don't wish to
worry about multi-homing.
The recent PKB security proposal removes some of the difficulties with
the need for previously set up security associations.
Thus the same set of additional end-to-end options that have to be processed
to support Mobile IP get you (b), always provided that the host can find out that
the original route is no longer viable, and can direct the packet to the right exit.
It seems to me that the discussion of transport level multihoming is missing
a fundamental effect of having multiple addresses for the host - The choice of source address used by a host affects the routing of both outgoing and the subsequent return packets if the letter of the globally aggregatable unicast addressing scheme is
adhered to. The effect is not just local but determines the exit point which an
outgoing packet takes from its originating domain and the path that the packet takes
all the way to the default free zone. Similarly, incoming packets have to take the
path through the domains which delegated the destination address. Thus multihomed
hosts in IPv6 are much more involved in route determination than was ever the
case in IPv4.
Exposing the multiple addresses to the application through the transport layer,
in the way that SCTP does, allows the application to subvert routing policies
which the domain may wish to have obeyed. It could be said that SCTP offers
mechanism without full understanding of the consequences.
Regards,
Elwyn Davies
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]
> Sent: 04 April 2001 16:10
> To: Margaret Wasserman
> Cc: multi6@ops.ietf.org
> Subject: Re: Requirements [was Re: Transport level multihoming]
>
>
> Thanks Margaret for getting some precision into the discussion.
>
> Margaret Wasserman wrote:
>
> ...
> > Let's make a distinction between the ability to do two
> > things:
> >
> > (a) Establish and use new upper layer communication
> > sessions (i.e. TCP connections).
> > (b) Maintain existing upper layer communication sessions.
> >
> > Is it required that an existing IPv6 stack be able to do (a)
> > and/or (b) in the following site multi-homing situations?
> >
> > (1) When both (or all) of the multi-homed site's
> > connections to the Internet are working?
> >
> > Obviously, we need (a) and (b) to work.
> >
> > (2) When one of the multi-homed site's connections to
> > the Internet stops working?
> >
> > We need (a). Do we need (b)? Or is acceptable
> > to require host software updates to obtain
> > reliable connections in this situation?
> >
> My answer is no, it would be a very serious mistake to require (b)
> in this case. It would result in an undeployable solution.
>
> Brian
>
>