I wrote:
So,
another way of multihoming critically depends on replacing the layer-4
protocols with something that doesn't intermingle the IP address with
the connection identifier.
Wrong. As is stated in my ID that:
On the other hand, with end to end multihoming, multihoming is
supported by transport (TCP) or application layer (UDP etc.) of end
systems and does not introduce any problem in the network and works
as long as there is some connectivity between the end systems.
end to end multihoming may be supported at the application layer
by trying all the available addresses, which is what DNS and
SMTP are actually doing.
To my surprise, I've found that the current (2017) happy eyeball
already does so as is stated in rfc8305:
: Appendix A. Differences from RFC 6555
:o how to handle multiple addresses from each address family
So, we are ready for end to end multihoming for which multiple
PA addresses are enough and /24 is not necessary. Though
not all the application protocols may support it, DNS, SMTP
and HTTP(S) should be good enough as a starter.
It should be noted that happy eyeball strongly depends on
DNS, even though someone might think DNS not guaranteed.
Your web server is multihomed if you assign it PA
addresses assigned from multiple ISPs and register
the addresses to DNS. You don't have to manage BGP.
TCP modification is just an option useful for long lasting
TCP connections.
A major obstacle for it, as most of you can see, is that there
are people who can't distinguish IP address changes by mobility
and by multihoming. Such people will keep reinventing MPTCP.
Masataka Ohta
