Hacker News Reader

Comment by kevin_thibedeau | Hacker News Reader

IPPROTO_SCTP does this today. Just have to convince middleware/box vendors to support internet protocol.

Where this conversation might have some points would be that you don't typically have these middle boxes within a single data center, so you could try to ignore them.

Until you remember that you have datacenters that need to talk to each other and then this strategy doesn't work.

You'll also need to convince several operating system maintainers to build/optimise their implementation first.

I wouldn't have any trouble ignoring middlebox software (or adding a TCP fallback with a big warning that something suspicious is interfering with the connection) but Windows and macOS still lack proper SCTP support, Linux' SCTP support has some performance issues and usermode raw sockets will probably need to bypass several OS sandboxes to be viable.

That said, in server to server connections SCTP can probably be used just fine.

…and Microsoft and Apple if your endpoints include Windows, IOS or MacOS. All of those have 3rd party drivers but I don’t think any of them come with SCTP support out of the box.

It's a no-go if they did anyway at the moment, the number of endpoints that's behind a NAT box that only knows about UDP and TCP is huge.

With the rise of IPv6 that may soon no longer be a problem. Plus, server to server communications usually aren't behind NAT boxes.

IPv6 is such a pain in the ass to deploy that people developed IPv6 NAT. For more than a decade the protocols to delegate an IPv6 subnet to a customer at the edge were missing. With PPPoE the situation was basically that you'd get a dynamic /64 on the PPPoE link (what a waste) and then have to manually configure the local IPv6 subnet on the CPE. IPv6's failure was largely self inflicted by failing to make it easy for ISPs to implement.

DHCPv6 and its prefix delegation extensions have been out since 2003. It took longer for IPv4 to receive DHCP support than it took IPv6 to get DHCPv6 (which was complicated by the stateless vs stateful debate). Back when IPv6 was standardized, DHCP was just two years old and wasn't a common method for assigning IP addresses in ISP networks.

IPv6 definitely got off on a rocky start but none of that has mattered for decades now. If IPv6 deployment is still such a pain, that's because of either your choices of the choices of your preferred vendors.

Except that wireless router manufacturers use ancient SDKs that are based on Linux kernels and tools that were typically 5+ years out of date as they were frozen by the hardware designers early in silicon development. It took a long time for upstream tool updates to trickle all the way down the hardware development path and into shipping consumer gear. IPv6 support for an ISP was still really difficult in 2010 because of that despite the protocols being released in 2003. I know because I tested a bunch of consumer gear back then and working IPv6 support was still hit and miss. Things are far better today.

Reply on news.ycombinator.com