The internet runs on a handful of core protocols, with TCP and UDP being the workhorses that handle nearly all our data. But what happens when you try to use something else? A curious experiment sending packets with made-up transport protocols across the internet reveals the hidden constraints of our digital infrastructure and why innovation at the transport layer has become nearly impossible.
Protocol Ossification: The Internet's Hidden Problem
The internet suffers from a condition known as protocol ossification - where the widespread deployment of middleboxes, firewalls, and NAT devices has effectively locked us into using only TCP and UDP for transport. While IP networks should theoretically forward any protocol, the reality is far different. As one commenter explains, The internet has standardized around TCP and UDP. There are too many devices in most paths that will not be able to handle other protocols. This ossification happens because network equipment manufacturers and operators optimize for the protocols they see most often, breaking compatibility with anything new or different.
SCTP (Stream Control Transmission Protocol) serves as the perfect example of this problem. Despite being technically superior to TCP in many ways, it remains virtually unused across the public internet.
SCTP is fascinating because it's one of the backbone technologies that makes communication possible for most people on the planet (as the mobile network stack pretty much relies on it), yet it's effectively unsupported on almost every consumer device.
While SCTP powers critical telecommunications infrastructure internally, it can't traverse the public internet reliably. This paradox highlights how even well-designed, standardized protocols can fail to gain adoption when faced with the reality of how networks are actually built and managed.
NAT: The Internet's Biggest Roadblock
Network Address Translation (NAT) devices represent the most significant barrier to protocol innovation. NATs work by tracking connections using transport-layer fields - specifically the port numbers in TCP and UDP headers. When confronted with an unknown protocol that doesn't have these familiar fields, most NAT devices either consume an entire IP address (quickly exhausting available addresses) or simply drop the packets.
This limitation is particularly problematic for home users. As one commenter noted, Every home user is behind a NAT. While you can send any protocol between datacenter servers, IPv4 home users are stuck with TCP or UDP. Even in the experiment described in the article, packets using custom protocols sometimes made it through once but were dropped thereafter, likely because firewalls couldn't match them to existing connection flows.
The Future: Protocol Tunneling and IPv6
To overcome ossification, modern protocol designers have adopted a pragmatic approach: tunneling new protocols inside UDP. QUIC, which powers HTTP/3, exemplifies this strategy. Rather than fighting the system, QUIC embraces UDP as a substrate and builds its innovations on top.
This approach creates tension between innovation and security. Network administrators often resist these developments because they break existing security tools. As one network professional explained, From an enterprise security perspective, it breaks a lot of tools. You can't decrypt, IDS/IPS signatures don't work, and you lose visibility to what is going on in your network.
IPv6 offers some hope for protocol diversity, as it eliminates the need for NAT in many scenarios. However, even with IPv6, firewalls and middleboxes may still block unfamiliar protocols. The transition to IPv6 remains frustratingly slow, with many corporate networks still relying on IPv4 address space.
The experiment described in the article confirms what network engineers have long suspected: the internet has become a highly specialized environment optimized for a small set of protocols. While you might get lucky sending a single packet with an exotic protocol, building reliable communication requires working within the constraints of what the network actually supports, not what it theoretically should.
For the foreseeable future, TCP and UDP will remain the only viable transport options for public internet traffic, with innovation happening primarily through tunneling and layering rather than through new transport protocols.
Reference: What would happen if we didn't use TCP or UDP?
 |
|---|
| Firewall rules limiting outbound traffic represent network constraints on protocol innovation |