Mptcp: Moving laptop from GBit to wireless without applications noticing?
redhat.com
redhat.com
I will say that for seamless wireless/wired switching, Linux bonding works very well. ~15+ years ago I had my laptop set up with eth and wifi bonded, with eth as the preferred, I believe using link-beat as the method. I could be running a big copy, plug in the ethernet and the transfer rate would almost instantly shoot up, and then when done I could unplug and all of my connections would stay up.
As WiFi got faster and faster, I used this less and less, so I haven't had it set up for for quite a few years now. But it does show the promise of MPTCP.
Before that I was even doing awful things like forcing the same IP onto both eth and wifi :D
No need to bond interfaces or apply the same IP to both interfaces. Let them both acquire different IP addresses in the same subnet. Linux will start announcing its ARP replies on the ethernet path since it has a better path metric. Thus the return path for both the wifi IP and the ethernet IP will become the ethernet link. Any existing connections that were traveling over the wifi link will just move onto the ethernet link automatically.
The only difficulty is new connections. Since the ethernet path has the better metric, new connections will establish with the ethernet link's IP address. But the routing table can be adjusted to instead make the wifi link's IP address the default for both the wifi and the ethernet links. Then new connections will always use the wifi IP, and will migrate over to the wifi link when the ethernet link disappears.
This should work as long as your wifi link always remains up whether or not you're in the dock.
As for rp_filter, it's set to "2" on my machines, which seems to allow return packets on the "wrong" port as long as it's an address that any other port owns.
For MPTCP, as of today the applications over the mptcp-stream (which has subflows over the 2 media) need to be modified to use MPTCP, or an additional layer like with shadowsocks needs to be used to transparently encapsulate traffic over the link.
With the tooling already there, I think this makes for an excellent use case for MPTCP.
If aggregation of bandwidth over the various underlying media is important for you: depending on the exact mode, aggregation might not work. Even if working, via bonding you might only get aggregation if the traffic goes over multiple TCP channels, while MPTCP also aggregates for a single TCP channel.
It's still there but there hasn't been a need for a protocol to really use it. Protocols like HTTP(S) could really use the SCTP benefits but those need solid client implementations; server protocols like DNS or FTP are restricted more by their own limitations than by TCP, really. Of course you'll find niche use cases where SCTP would've been a godsend, but without proper Windows support _and_ broken middleboxes ruining everybody's internet experience, SCTP was sort of doomed from the start.
MPTCP has some compatibility advantages and TCP-inside-TCP allows for solid client side implementations that can be linked to the userland code itself (https://github.com/ngi-mptcp/curl/wiki/Multipath-TCP-on-Wind...) without elevating credentials; sadly, SCTP didn't have that luxury, as Windows (rightfully) restricted access to raw sockets not long after SCTP began to gain popularity among its fringe group of supporters.
With UDP, TCP and SCTP, if you need to change ports in the header, then you need to update the checksum. The traditional TCP/UDP checksum is kinda crap, but this works in its favour here, because you can just perform a corresponding and easy adjustment of the header.
SCTP protects packets with a strong CRC32C checksum. This is on the whole a good thing, but you can't do the twiddle trick with CRC32C. If you're rewriting ports, you need to recalculate the checksum over the entire packet.
This means that linerate SCTP NAT accelerators have never existed. On the whole, what SCTP NATs exist only do address translation: If two people try to establish outbound SCTP connections from the same source port, the second person's connection just gets dropped by the NAT.
OTOH, last I heard, Apple uses MPTCP for Siri, so you've got a popular use with a strong influence on mobile networks, that's going to be pushing for at least safe fallback, if not actually working.
There will be issues with middleboxes, but in my opinion middleboxes have been given more than enough time to stop freaking out about network interception after the problem with TLS 1.3 was discovered.
The Red Hat people primarily seem to focus on this as a backend/server-to-server communication method which means that MPTCP (or SCTP) can be rolled out without too much trouble. A big problem SCTP has is that there is no good implementation outside Linux, and even on Linux performance is suboptimal. MPTCP can be linked into the application at runtime (https://github.com/ngi-mptcp/curl/wiki/Multipath-TCP-on-Wind...) so that's not necessarily an issue here, which helps.
And: Speak nothing of BigCloud load balancers...
Multiple addresses/prefixes are a required component for IPv6 to function, which I suspect is often the biggest source of misunderstanding from legacy IP competency.
If you need a stable prefix for a host, use a ULA or your own GUA. If you need to provide services from 2 or more upstream networks, configure the host with addresses from each of the delegated prefixes from those networks. If you need to do all of the above, there’s nothing preventing you from configuring them all simultaneously. You can even use the IP and routing stack to provide selective service access and trust thresholds.
Prefix mobility is something that should have been anticipated when IPv6 was being hashed out, and would have made many things much easier, but it’s far from critical, and gives IPvA an easy killer use case.
Alternatively you could register an IPv6 address of your own but you'd need to find an ISP that will let you use that, which can be harder than you'd hope, or you could tunnel your entire connection through the cloud in a semi-NAT system.
This isn't a problem for 99.9% of people and I'd wager it's not a problem for over 80% of businesses either. However, for companies with zealous network administrators and IP-based access control this is a real problem that needs solutions like NAT.
Those are what ULA's do. A local router that provides global addresses and ULAs solves all your problems, and that's the default behaviour of OpenWRT (and probably other routers). If you want traffic to not leave your local network, listen to your ULA (fd00::whatever) and call it a day.
But it still does not solve the problem of adding a lot of latency.
Even Tor is vulnerable to timing correlation attacks, imagine everything else, given how leaky most protocols are...
Once my traffic is cleartext, a TCP connection to 209.216.230.240 is enough to infer I'm browsing this site.
shadowsocks proxy seems like the best choice, allowing transparent proxy for TCP applications, but also needs 2 helper systems for the setup.
Next best choice seems bonding, just needs helpers on the LAN.
[0] https://freebsdfoundation.org/project/multipath-tcp-for-free...
wow, did he write that 5 years ago?
I guess I could just google it, but does anyone know if the OSI stack is portable to the application layer, the way that apenwarr was promoting, and the way that mptcp simulates? Since the time of that article, I've always wondered if that was the case. Or is OSI "broken" in its layering, like TCP/IP.