Aside from terrible middleboxes, SCTP also suffered from a lack of kernel implementations on non-Linux platforms and performance issues in the existing implementation.

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.

I think one other major reason SCTP never went anywhere because performant SCTP NAPT is impossible.

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.

In MPTCP each connection from the bundle appears/behaves just like a single "traditional" TCP connection. Therefore - at least in theory - there should be no issues with NAT/middleboxes. In fact this has been a major design goal from the start.

MPTCP uses new TCP options. Middleboxes could mess those up.

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.

I think that's great until those middleboxes start trying to parse TLS headers. TLS 1.3 looks like TLS 1.2 because of the same protocol ossification problem.

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.

Popular IPv4 to IPv6 transition mechanisms broke anything that wasn't TCP/UDP/ICMP, just as well.

And: Speak nothing of BigCloud load balancers...

Newer protocols like QUIC are encapsulated by UDP instead of adding new protocol numbers. NAT box breaks because NAT must be implemented for each protocol (port number not at IP level).

SCTP is over 20 years old. I think the explanation for today's situation is slightly more complex than NAT boxes not having enough advance notice. NAT isn't allowed by the TCP/IP specs, for the exact reason that it breaks IP and new internet applications. Everyone was supposed to move to IPv6 with enough addresses so the temptation to use NAT would go away. Instead we ignored the stewardship of IETF and ISOC, and just adapted to the laissez faire world of middleboxes and broken IPv4.

So there is a difference between what people are supposed to do and what people actually do. What I am wondering now is why IPv6 didn't adapt NAT as a first class feature, if IPv6 added something like port number in IPv6 header, NAT could not break protocols. It seems IPv6 strongly resists NAT, but in reality, people still use NAT on IPv6.

Using NAT with IPv6 betrays a lack of understanding with how it’s supposed to be used, and a stubborn continuation of IPv4 kludges.

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.

Using NAT with IPv6 sounds tragic, hopefully this isn't common.

There are reasons to do some kind of NAT across IPv6. For example, switching ISPs may throw your internal network addressing in disarray which can be either a pain or a massive problem; NPTv6 will prevent that from being too much of an issue inside the premises, which should cover 95% of the issues. The best thing is that you keep most of the advantages of IPv6 (all addresses and all ports publicly reachable, foregoing the need for dangerous stuff like ALG) despite the address translation.

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.

>switching ISPs may throw your internal network addressing in disarray which can be either a pain or a massive problem

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.