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 leastSupporting 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, or
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.