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