> multiple/changing IP addresses IPv6 supports multiple methods of multi-homing. > For example, couldn't they have extended port numbers to 128 or 256 bits an

> multiple/changing IP addresses IPv6 supports multiple methods of multi-homing. > For example, couldn't they have extended port numbers to 128 or 256 bits and recommended that IP flows be identified just by the pair (source port, destination port) instead of the current (source IP, source port, destination IP, destination port)? Port numbers aren't part of the IP layer. Regardless, IPv6 contains a 20 bit flow label (https://datatracker.ietf.org/doc/html/rfc6437 https://datatracker.ietf.org/doc/html/rfc6437) that can be used to indicate a specific (sub)connection. I don't think it's ever used, though. > That would make it possible, for instance, to start a HTTP upload via an LTE modem but finish it on WiFi without interrupting the connection. That's already technically possible, but not in the IP layer. Multi-path TCP solves this problem exactly how you would think, by agreeing on an identifier between two hosts and performing a handshake over an alternate route using that key. iOS uses it by default for various services. This can even be used to bundle the connection (upload over LTE and WiFi at the same time for maximum network speed) or theoretically to do weird stuff like upload over ethernet and download over WiFi. Sadly, many Android devices still run old Linux kernels so MPTCP is disabled on there by default, though more recent devices should support it just fine. Many networked clients also don't use it, though I'm not sure why; it's just an option flag in TCP, if the network is fucked up by corporate middleboxes, the connection will just behave like a normal connection. If you're ever writing a TCP server or client, consider enabling MPTCP by default!