SCTP is a superior protocol, but it isn't implemented in many routers or firewalls. As long as Comcast / Verizon routers don't support it, no one will use it.

It may be built on top of IP, but TCP / UDP levels are important for NAT and such. Too few people use DMZ and other features of routers / firewalls. Its way easier to just put up with TCP / UDP issues to stay compatible with most home setups.

Why do the routers involve themselves at the transport layer? Can't they just route IP packets and leave the transport alone?

Firewalls -- whose firewalls are we talking about here? If a client (say, home user) tries to initiate an SCTP connection to a server somewhere, what step will fail?

> Why do the routers involve themselves at the transport layer? Can't they just route IP packets and leave the transport alone?

Because they have to do NAT, at least on IPv4.

> Firewalls -- whose firewalls are we talking about here? If a client (say, home user) tries to initiate an SCTP connection to a server somewhere, what step will fail?

Because the connection tracking that's needed to even recognize whether a packets belongs to an outbound or an inbound connection needs to understand the protocol.

I haven't tried it and am not terribly familiar with SCTP, but from skimming a few references I suspect it would fail when the NAT logic decides it's never heard of protocol number 132 and drops the incoming INIT_ACK on the floor.

You can tunnel SCTP on top of UDP. Port 9899.

https://www.ietf.org/proceedings/48/I-D/sigtran-sctptunnel-0...

This is an improvement --- it was dumb of SCTP to try to claim a top-level IP protocol for this --- but only marginally, since lots of firewalls won't pass traffic on random UDP ports either.

Why was that dumb of SCTP? What should it have done instead?

Used a UDP port. Making new IP protocols is literally what UDP is for.

Other than getting through broken routers, what's the advantage of building a protocol on top of UDP rather than IP?

("Getting through broken routers" is certainly a significant advantage; I'm just asking if that's the only good reason to not build directly on IP.)

The only "advantage" to declaring an IP protocol is that you might save 8 bytes and a trivial checksum. Mostly, though, declaring an IP protocol is a vanity decision.

I'm wondering the reverse: what's the advantage to building on UDP, other than passing routers that for some reason are inclined to pass UDP but reject IP protocols they don't know? You said that this was "what UDP was for", and I was hoping for some more detail there on why UDP helps. As you said, it's just 8 bytes and a trivial checksum.

The advantage to building on UDP is that it gets through (some) middleboxes; that's what the 4 bytes of port numbers buys you. That, and the fact that UDP is designed to be the TCP/IP escape hatch for things like SCTP that don't want TCP's stream and congestion control semantics.

So there's no advantage other than getting through broken middleboxes?

No, another advantage is that you can do UDP entirely in userland without privilege.

What allocating a new IP protocol says is pretty close to "all bets are off, and we're carefully taking responsibility for how every system that interacts with TCP/IP headers will handle these packets". Since SCTP doesn't need that, there's no upside. It's vanity and bloody-mindedness.

Very true. I'd of course run tests, but I would guess port 80 would work these days because of QUIC. Even port 53 is probably locked down to whitelisted hosts.

Private ones usually do. (outgoing)

Corporate ones sure don't. Even outgoing HTTP is passed through proxies on most bigco networks I've worked at.

Yes. But I don't think that corporate firewalls matter when it comes to user adaption. If you need to work with SCTP in your company, you'll get your firewall rule, if not you don't.

If they want to only allow proxied HTTP, that's their decision and developers should respect that, and not mask everything under HTTP. Their administrators made a substantial effort to forbid everything, why would honest person try to overcome their effort?

Home routers is another matter, home users don't make conscious decision about it, but in my experience UDP works just fine (because a lot of games use it) and it should be good enough for any protocol.

Because in many cases, those administrators don't even realize they're breaking the network. They just run a botched config that they inherited from their predecessors or something like that.

You might say that they're clueless and shouldn't be allowed near networking equipment (and you might even be right) but it's not going to change a thing. For the foreseeable future, working around broken environments is all we can do.

It's not. Talk to them. If you really need port XYZ open because your task requires that, you'll get the port open.

To your point, IPv6 has been around 20 years, the whole time we know we're running out of IPv4 addresses and adoption is still around 20%.

However, the high turnover for mobile phones has allowed more aggressive changes to the networking stack. Perhaps this, in addition to IPv6, would make something like SCTP easier to adopt widely?

"Still" seems a bit disingenuous when considering the current trajectory IPv6 adoption is on. [0] Yah it's happening slowly, but it does seem to be pushing ahead.

[0] https://www.google.com/intl/en/ipv6/statistics.html

That graph has a couple doglegs that make it look exponential.

The last dogleg was January 2015. And since then it’s been linear (with a little stall this month) at about 5% of the Internet converting per year. That’s another 15 years to convert the rest, unless there’s a new dog leg up.

Also percentages don’t work the way humans think they do. Especially when the number of devices is constantly climbing. That may just indicate that some fraction of new hardware is ipv6 but little old hardware is being updated.

We may well have ~2 billion machines on ipv4 pretty much indefinitely, slowly being diluted by addition of new hardware.

Agreed. I say IPv6 is inevitable, but it's not like the IPv4 addresses will expire.

The economics going forward will be interesting. I've seen some low-end VPSes charge a lower rate for machines that are IPv6-only.

Cloudflare enabled domains can tunnel ipv6-only hosts for ipv4 clients.

Offtopic, but did you notice the 3-4% spikes on Saturdays? And the dips on workdays.

I assume workplaces have a lower adoption rate due to enterprise inertia. Or is there another explanation?

You're absolutely right. I've read in other articles that IPv6 jumps up on weekends. IPv6 adoption is incredibly skewed. It's much higher in things like cellular networks and in developing countries. I think the weekend jump is attributed to cellphones (not sure if I'm connecting the dots or if that's what the consensus is).

How is that disingenuous? I don't think it matters what the curve looks like when it spans 10 years and ends up at 20%. There were implementations released 10 years previous to the graph's start. I wasn't implying it would never happen, just that even for something that's inevitable like IPv6, adoption is glacial.

I think disingenuous is the wrong word; but the curve does matter: 20% in 10 years indicates 100% in 50 years if the curve's a line, but it's not.

I dove into the world of curve fitting (wee!) and my prediction[1] for 95% IPv6 adoption is around the year 2025: https://imgur.com/a/LyBJn (fitted to the logistic curve[2], x=0 is basically 2010, y is percent adoption)

[1] Which you should completely trust because I've been doing this for all of 20 minutes!

[2] https://en.wikipedia.org/wiki/Logistic_function#In_economics...

Thanks for taking the time to do that!

Lets say 20% adoption means we're 40% of the way through the transition. The slope for IPv6 looks better and better every day, but overall it's not a great adoption story for tech that inevitably has to happen. (not to discourage or minimize the all the hard work done in getting IPv6 this far)

Which is frankly horrifying considering the reference implementation was released in FreeBSD 7. That really ought to scare people from purchasing any of those routers/firewalls that don’t support it.

It's not a matter of time in the wild, it's a matter of adoption and cost priorities. Until the past several years, most SoHo routers were super constrained wrt CPU, memory, and ROM, so adding support for a new transport layer protocol would involve an unacceptable cost increase in what has rapidly turned into a race-to-the-bottom commodity industry.

So you end up with a chicken-and-egg problem: router manufacturers aren't going to add support for it unless there's sufficient demand, and there can't be sufficient demand because very few people can use and rely on it.

Interestingly SCTP is used for WebRTC's data channel. Emscripten uses it to emulate UDP.