What would happen if we didn't use TCP or UDP?

Original Article ↗ Hacker News Discussion ↗

SCTP as “better TCP” and why it failed on the Internet

  • SCTP offers message semantics, multiple independent streams, and optional reliability; it underlies WebRTC data channels and is heavily used in mobile/telecom cores.
  • Despite technical merits, it’s “effectively unsupported” on consumer devices: kernel implementations are rare/slow, userland needs raw sockets, and middleboxes/NATs often drop or mangle non‑TCP/UDP protocols.
  • Many see SCTP as an example of protocol ossification: new L4 protocols (SCTP, MPTCP) are blocked by middleboxes that only understand TCP/UDP.

QUIC vs SCTP/TCP and why QUIC exists

  • QUIC chose UDP precisely because UDP is widely passed by routers and NATs; SCTP over bare IP generally can’t traverse home NATs.
  • QUIC integrates TLS to cut round trips and improve TTFB, especially on high‑latency links, and provides multiplexed streams like SCTP/MPTCP.
  • Some ask why we don’t “just use QUIC instead of TCP”: answers note QUIC is young, has implementation bugs (e.g., HTTP/3 in some browsers), uneven language/OS support, and far less operational experience than TCP.
  • Viewpoint: QUIC is a powerful third option between TCP and UDP, but unlikely to fully replace TCP; protocol choice will remain application‑specific.

Middleboxes, NAT, and protocol behavior

  • Consumer NATs multiplex based on transport‑layer ports; they’re usually only aware of TCP/UDP (and a few special cases like ICMP). Unknown protocols may consume scarce IPv4 addresses or just be dropped.
  • One report: a Netgear router “zeroed” the first 4 bytes of custom packets, apparently assuming they were TCP/UDP ports.
  • Discussion clarifies layering: IP has protocol numbers, not ports; ports live in TCP/UDP/SCTP headers and are protocol‑specific.
  • Speculation about the article’s “single packet got through” cliffhanger: likely a firewall created a flow for the first packet, then dropped later ones when it couldn’t match them.

DNS over TLS vs HTTPS and censorship

  • DoH is described as primarily an anti‑censorship and anti‑ISP‑logging measure: port 443 traffic is hard to block wholesale, whereas DoT/853 is trivially blockable.
  • Others argue both DoH and DoT rely on encryption for privacy; DoH’s “obscurity” undermines network operators’ ability to manage DNS on their own networks.

IPv6 design and deployment friction

  • Some wish early IP had stronger header integrity, forcing earlier IPv6 and cleaner protocol evolution; others note IPv6 was initially over‑engineered (mandatory IPsec) and hard to implement.
  • Debate over SLAAC vs DHCPv6, /64 vs /56+/48 allocations, and Android’s lack of DHCPv6 complicating home subnetting; many ISPs don’t follow best‑practice prefix delegation.

Raw sockets and other stacks

  • Raw/packet sockets (AF_PACKET, AF_INET+SOCK_RAW) let you bypass TCP/UDP to experiment with custom transports, but require elevated privileges and generally don’t survive through NAT/firewalls.
  • Thread briefly mentions alternative or historical stacks/protocols (IL, IPX, UUCP/NNCP, Plan 9’s flexible addressing, Infiniband, Ethernet WAN) as reminders that TCP/UDP/IP were not inevitable.