Linux net-next gains core in-kernel QUIC transport stack

A 15-part series posted to the netdev list proposes the first substantial in-kernel QUIC implementation for Linux, aimed at net-next. The work, led by Xin Long and carrying an Ack from networking maintainer Paolo Abeni, treats QUIC as a first-class transport rather than a userspace library bolted onto UDP.

QUIC (RFC 9000 and related RFCs) runs over UDP and combines TLS security, multiplexed streams, loss recovery, and connection migration. Putting that machinery in the kernel matters for two audiences. Kernel clients such as SMB and NFS can finish a handshake through the existing net/handshake path, then exchange data on ordinary in-kernel transport interfaces with little protocol-specific glue. User-space programs get familiar socket calls (listen, accept, connect, sendmsg, recvmsg, and the usual sockopt and name helpers) on IPPROTO_QUIC sockets, plus ALPN-based demux so different processes can share the same UDP endpoints by application protocol.

The design deliberately avoids a simple UDP upper-layer protocol. Connection migration and multipath need more than one UDP endpoint per QUIC association, and a single UDP socket may back many QUIC connections; modeling QUIC like TCP or SCTP on top of UDP tunnels is meant to keep those cases scalable. The TLS handshake itself stays in userspace; the kernel handles record protection, streams, connection IDs, path management (including PLPMTUD), packet-number spaces, timers, and a New Reno congestion controller once keys are installed.

If merged, the series would give Linux a shared QUIC datapath for both kernel subsystems and POSIX-style applications, with room later for zero-copy sendfile paths and crypto offload, instead of every stack reinventing the same UDP framing and recovery logic.