[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mutli6 meeting in Vienna
On donderdag, mei 15, 2003, at 17:05 Europe/Amsterdam, Christian
Yes, I was very imprecise here. There are several things that can
happen, including the requirement to change something. I think it would
be a mistake to require both hosts and routers to change, as it pretty
much doubles the required deployment efforts needed to get this off the
ground. Requiring applications to change is absolutely a nonstarter as
we'll have single homed applications for decades that way.
I think we have to qualify "break". I would personally say "augment"
rather than "break".
The basic idea should be:
1) An unmodified implementation continues working, and receives at
Supporting single homed correspondents is essential but I don't care
much for single homed hosts in a multihomed site. Upgrade already. It's
not like there is a huge installed base of stuff that isn't supported
any more in IPv6.
the same quality of service as if the local site was not multi-homed,
the correspondent node was not multi-homed.
In practice, that means that we cannot "break" transports, IP or IPSEC.
However, we should be able to augment each of them.
It would be better if we didn't have to...
It might be challenging to change autoconfiguration so it can assign an
identifier as well as a number of locators.
If auto-configuration is augmented to provide support for multi-homing,
then augmented implementations should take advantage of it.