5 ms·
Since we're already talking about IPv6, I'll take the opportunity to bring up a topic I've been thinking about recently. If they were already redesigning the IP
by pkkm 3y ago
Since we're already talking about IPv6, I'll take the opportunity to bring up a topic I've been thinking about recently. If they were already redesigning the IP protocol, why didn't the creators of IPv6 ensure good support for multiple/changing IP addresses? 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)? 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.
- Faaak 3y agoHow do you route all these IP addresses to the correct destination ? Actually all the IPv6 prefixes are know to all big routers (ASes, but that's getting technical). It's called the default free zone and it is growing by the day. The more non-aggregatable IPs, the more space on the route table of routers is occupied. And this space is really expensive
- jeroenhd 3y ago> 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!
- nicolaslem 3y ago> If you're ever writing a TCP server or client, consider enabling MPTCP by default! How does one do that?
- jeroenhd 3y agoDepends on your programming language and platform. If you're using the C API on a Linux kernel, use IPPROTO_MPTCP instead of IPPROTO_TCP. With Go, call SetMultipathTCP(true) on listeners and other connections. On iOS, set MultipathServiceType to NSUrlSessionMultipathServiceType.Handover for your NSUrlSessionConfigurations. Depending on your platform, you may need to do a quick "is MPTCP supported" check with fallbacks, i.e. when you need to support older Android, Windows, or BSDs, or an old (<5.6) Linux kernel.
- pkkm 3y agoThank you. I had no idea this existed but it's the kind of thing I was looking for.