That simple, implicit standard exists since RFC793:

  Simultaneous initiation is only slightly more complex, as is shown in
  figure 8.  Each TCP cycles from CLOSED to SYN-SENT to SYN-RECEIVED to
  ESTABLISHED.



      TCP A                                            TCP B

  1.  CLOSED                                           CLOSED

  2.  SYN-SENT     --> <SEQ=100><CTL=SYN>              ...

  3.  SYN-RECEIVED <-- <SEQ=300><CTL=SYN>              <-- SYN-SENT

  4.               ... <SEQ=100><CTL=SYN>              --> SYN-RECEIVED

  5.  SYN-RECEIVED --> <SEQ=100><ACK=301><CTL=SYN,ACK> ...

  6.  ESTABLISHED  <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

  7.               ... <SEQ=101><ACK=301><CTL=ACK>     --> ESTABLISHED

                Simultaneous Connection Synchronization

                               Figure 8.

This is true, but the beauty of UDP is that it's basically just a raw socket with a tiny 8 byte header slapped on top, with 2 bytes for source port, 2 bytes for destination port, 2 bytes for length, and 2 bytes for a checksum.

You could slap a UDP header on top of the TCP header and get the benefits of TCP with the hole-punching capabilities of UDP, provided you implemented some kind of keep-alive functionality and an out-of-band way of telling the "server" to establish an outbound connection with the "client". Or use QUIC, assuming it fits the use case.

At least there's an explicit standard for signalling: RFC 6887 Port Control Protocol. Many routers also support it.

But it's often disabled for the same reason as having router-level firewalls in the first place.

From what I recall, one downside to SCTP is that things like resuming from different IP addresses and arbitrarily changing the amount of connections per socket didn't work well in standard SCTP. Plus the TLS story isn't as easy. QUIC makes that stuff easier to work with from an application perspective.

Still a fascinating protocol, doomed to be used exclusively as a weird middle layer for websockets and as a carrier protocol for internal telco networks.

Unfortunately most of the existing communication protocols that are standardized conform to a broken model of networking where security is not provided by the network layer.

Cryptography can't be thought of as an optional layer that people might want to turn on. That bad idea shows up in many software systems. It needs to be thought of as a tool to ensure that a behavior is provided reliably. In this case, that the packets are really coming from who you think they are coming from. There is no reason to believe that they are without cryptography. It's not optional; it's required to provide the quality of service that the user is expecting.

DTLS and QUIC both immediately secure the connection. QUIC then goes on to do its stream multiplexing. The important thing is that the connection is secured in (or just above) the network layer. Had OSI (or whoever else) gotten that part right, then all of these protocols, like SCTP, would actually be useful.

https://github.com/TheusHen says you're 14 years old.

The project is very impressive, as is https://github.com/TheusHen/ternary-ibex and having papers: https://orcid.org/0009-0009-5055-5884

What's the education path for a 14 year old that does this stuff?

Thanks for sharing. I want to ask you something: I understand that with IPv6 the idea is that every household receives several of IPv6 addresses so that every single IoT device has their unique IPv6 address and there is no NAT needed.

Would it be possible to use a dozen of IPv6 addresses at the same time? Like send one UDP packet over certain IPv6 interface, next packet over another IPv6 interface, and so on. If both sending and receiving end have access to multiple IPv6 addresses I can see how this significantly increases complexity for tracking.

Could you split up the traffic across dozens or hundreds of IPv6 source addresses?

> QUIC-based, NAT-free

I realize it's intended to be an unsupported edge case but I'm curious. What happens in the event a NAT is present along the IPv6 network path? Do you just forward a port the same as you would with the various IPv4 solutions and move on? Or does it break catastrophically? Something else?