Re: Requirements [was Re: Transport level multihoming]

[Margaret Wasserman <mrw@windriver.com>]

>Given the choice between remaining compatible with 'legacy' IPv6 stacks or
>providing a useful multihoming solution, which would you choose?

IMHO, it is imperative for any IPv6 multi-homing to retain 
compatibility with deployed IPv6 host implementations. It is
also imperative that we develop a more scalable multi-homing
architecture than the current IPv4 solutions.  I don't think 
that it is acceptable to compromise on either goal.

Please note:  I am using precise IPv6 terminology above.  I
specifically think that it is required to retain backwards
compatibility for host (non-router) implementations of IPv6.
It would be acceptable for an IPv6 multi-homing solution
to require router software updates at multi-homed sites.

I also have some questions regarding what type of compatibility
is required for host stacks.

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?

What types of transitions mechanisms should be able to
work with site multi-homing?  Do we require that a 
bump-in-the-stack or bump-in-the-API solution work with
site multi-homing?  Would we need (a) (as defined above)
or both (a) and (b) to work for these applications?

Before you say that we can compromise (b) in choice (2) or
in the BIS or BIA cases, please note that current IPv4 
multi-homing solutions do _not_ compromise on this requirement 
for current IPv4 nodes.

The Internet is a commercial concern, and operators need to 
provide the services that customers require.  If we design 
an IPv6 multi-homing solution that does not address all of 
the concerns addressed by the current IPv4 multi-homing
solutions, then we run that the current tunneling-based 
solutions will continue to proliferate.

If we decide that it is acceptable for hosts to require
software upgrades (from current deployed IPv6 implementations)
to achieve (b), then what type of upgrades are acceptable?

         (i)    Changes to the IPv6 addressing architecture?

         (ii)   Fundamental changes to the IPv6 protocol?

         (iii)  Changes to TCP, UDP or other upper layers?
         
         (iv)   Changes to DNS?

         (v)    Changes to drivers or lower layers?

I believe that (i), (iii) and (iv) would be required for a 
set of changes that I have in mind.  Would that be acceptable?

Also, are there things about IPv6 that we are _not_ willing
to sacrifice for a better multi-homing solution?  The most
likely (and most costly) victim is IPv6 Host Autoconfiguration.
IMHO, we should _not_ sacrifice Host Autoconfiguration for a
better site multi-homing solution.  I think we should have
both!  

These are the types of questions (and there are many more)
that the requirements document should seek to raise and answer, 
in close consultation with large operators and IT folks from 
large sites.

I would be happy to work with the author of the requirements
document to reflect these type of questions in the document and
seek consensus on the answers.

Margaret