William Herrin wrote:
Use Multipath TCP https://datatracker.ietf.org/group/mptcp/documents/
Doesn't work well. Has security problems (mismatch between reported IP addresses used and actual addresses in use) and it can't reacquire the opposing endpoint if an address is lost before a new one is communicated.
It merely means MPTCP is wrongly architected. Dynamically changing IP addresses is for mobility (if you don't mind location privacy), not for multihoming. The following way in my ID: The easiest way for applications know all the addresses of the destination is to use DNS. With DNS reverse, followed by forward, lookup, applications can get a list of all the addresses of the destination from an address of the destination. does not have any such problem and should be as safe as happy eyeball for two or more IPv4/IPv6 addresses. As for (long lasting) TCP, my ID says: With TCP, applications must be able to pass multiple addresses to transport layer (e.g. BSD socket). which implies addresses are supplied from applications by DNS look up. Though a client may, at the time TCP connection is established, send a list of its IP addresses to a server, which may have some security complications, it is simpler to let the server just rely on DNS: With DNS reverse, followed by forward, lookup, applications can get a list of all the addresses of the destination from an address of the destination. As I pointed out in the previous mail, DNS already supports end to end multihoming at the application layer to try all the addresses of name servers, on which other applications can safely rely. Masataka Ohta