Linux Kernel Network Feature Timeline

Linux networking evolves through incremental mainline releases rather than separate subsystem releases. The milestones below identify the first stable kernel containing each feature; later kernels may add protocol coverage, drivers, offloads, or userspace interfaces.

Network Feature Quick Facts #

Release dates follow the mainline tags in the Linux kernel Git history. Feature versions are cross-referenced with the KernelNewbies release summaries and the kernel networking documentation.

Kernel-Userspace Boundary #

Linux does not provide a syscall such as add_route() or create_veth(). Instead, userspace selects a kernel control interface and reaches it through general-purpose syscalls. Netlink, in particular, is a family of socket protocols rather than a syscall.

Most administrative operations require CAP_NET_ADMIN in the user namespace that governs the target network namespace. eBPF operations may additionally require CAP_BPF, CAP_PERFMON, or other capabilities depending on the program type, attachment point, and kernel version.

How the Recommended Interface Changed #

1. Early Linux used ioctls, socket options, and virtual files. Programs such as ifconfig, route, and arp issued network-device and routing ioctls. /proc/sys/net supplied global tunables, while firewall generations through legacy iptables used protocol-specific socket options.
2. Rtnetlink became the extensible network control plane. Linux 2.2 exposed links, multiple addresses, routes, neighbours, and traffic-control objects through NETLINK_ROUTE. The iproute2 tools (ip, bridge, and tc) therefore replaced the ioctl-oriented net-tools commands for new configuration.
3. Subsystem-specific Netlink families replaced fixed private ABIs. Generic Netlink and related protocols allowed commands and type-length-value attributes to evolve without changing a syscall. nl80211 replaced Wireless Extensions, nftables replaced the legacy iptables rule ABI, and newer ethtool operations use Netlink instead of device ioctls.
4. eBPF added a programmable data-plane boundary. The bpf() syscall manages programs and maps, but configuration remains split by attachment point: rtnetlink configures traffic-control and established XDP attachments, socket options attach classic socket filters, and BPF links provide file-descriptor lifetime management for supported hooks.
5. New control planes favor described Netlink APIs. Kernel networking development now documents Netlink families with machine-readable specifications. Applications should use those APIs, request acknowledgements and extended acknowledgements, and reserve ioctls or text-file parsing for interfaces without a supported structured replacement.

See the kernel’s Netlink introduction, rtnetlink(7), netdevice(7), and bpf(2) documentation for the corresponding UAPI details.

Rtnetlink #

The rt in rtnetlink means routing, but the interface has grown into the kernel’s general network-control protocol. A process opens socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) and sends RTM_* messages. Each message contains struct nlmsghdr, an object-specific fixed header, and aligned type-length-value attributes.

Rtnetlink supports three interaction patterns:

• Do request: create, replace, change, or delete one object and receive an acknowledgement.
• Dump request: enumerate an object class, such as all links or all routes. The kernel returns a multipart response terminated by NLMSG_DONE.
• Multicast notification: subscribe to groups for link, address, route, neighbour, rule, traffic-control, and other changes. Notifications use the same object messages as replies, which lets a program maintain a local cache.

Managed Objects #

RTM_NEW* does not always mean “create only.” Flags determine the mutation semantics:

Applications should also enable NETLINK_EXT_ACK. Extended acknowledgements can identify the rejected attribute, include a human-readable kernel message, and report policy constraints. A successful acknowledgement means that the kernel processed that message; it does not make a sequence of separate rtnetlink requests transactional.

Namespace and Consistency Model #

An rtnetlink socket operates in the network namespace with which it is associated. Most requests therefore see and modify only that namespace’s links, routes, rules, neighbours, and traffic-control objects. Link attributes can move a device to another namespace, while namespace-ID messages create references to peer namespaces.

Mutating requests generally require CAP_NET_ADMIN in the user namespace that owns the target network namespace. Read requests may still be restricted when they expose sensitive device or protocol information.

A dump is not an atomic snapshot. Objects can change while a multipart dump is in progress, and multicast notifications can be lost when the receive buffer overflows. A state synchronizer should:

1. Open and bind the socket to the required multicast groups.
2. Request a dump with a unique sequence number.
3. Match unicast replies by sequence number and sender port ID.
4. Process notifications arriving during the dump.
5. Detect ENOBUFS, interrupted dumps, and malformed attributes.
6. Discard the cache and repeat the dump when synchronization cannot be proven.

Scope Boundaries #

Rtnetlink controls network topology, addressing, forwarding, neighbours, and traffic control, but it is not the interface for every network subsystem:

The authoritative operation list is defined in include/uapi/linux/rtnetlink.h. The kernel also publishes machine-readable specifications for links, addresses, routes, rules, neighbours, and traffic control. Higher-level programs should use maintained libraries or iproute2 rather than reproducing UAPI structure layout and attribute validation manually.

Userspace Network Utilities #

Linux has no single userspace networking stack. Command-line tools, policy daemons, configuration renderers, routing daemons, and container plugins reach different kernel control interfaces. A higher-level command may therefore control a daemon instead of contacting the kernel.

Control and Dependency Paths #

The arrows describe runtime control flow, not package ownership. NETLINK_ROUTE, NETLINK_NETFILTER, and nl80211 are kernel protocols reached through AF_NETLINK sockets.

flowchart LR
    subgraph clients[Clients and Configuration]
        nmcli["nmcli / GUI"]
        networkctl
        netplan[Netplan]
        firewallcmd[firewall-cmd]
    end

    subgraph controllers[Daemons and Direct Utilities]
        nm[NetworkManager]
        networkd[systemd-networkd]
        wifi["wpa_supplicant / iwd"]
        firewalld
        iproute["ip / bridge / tc"]
        nft
        iw
        ethtool
        bpftool
    end

    subgraph apis[Kernel Control Interfaces]
        rtnl["NETLINK_ROUTE<br/>(rtnetlink)"]
        nfnl[NETLINK_NETFILTER]
        nl80211["nl80211<br/>(Generic Netlink)"]
        ethtoolapi["ethtool Generic Netlink<br/>or device ioctl"]
        bpfapi["bpf() syscall"]
    end

    kernel[Linux Network Kernel]

    nmcli -->|"libnm + D-Bus"| nm
    networkctl -->|"daemon IPC"| networkd
    netplan -.->|"generates configuration"| nm
    netplan -.->|"generates configuration"| networkd
    firewallcmd -->|D-Bus| firewalld

    nm -->|"internal Netlink"| rtnl
    nm -->|D-Bus| wifi
    networkd -->|sd-netlink| rtnl
    iproute -->|"internal libnetlink"| rtnl
    firewalld -->|"nftables backend"| nfnl
    nft -->|"libnftables + libnftnl"| nfnl
    wifi --> nl80211
    iw --> nl80211
    ethtool --> ethtoolapi
    bpftool -->|libbpf| bpfapi

    rtnl --> kernel
    nfnl --> kernel
    nl80211 --> kernel
    ethtoolapi --> kernel
    bpfapi --> kernel

The diagram answers the common nmcli dependency question directly:

1. nmcli constructs a request through libnm.
2. libnm sends the request over D-Bus to the NetworkManager daemon.
3. NetworkManager applies ordinary kernel network state through its own Netlink implementation.
4. iproute2 is an independent administrative client of the same kernel APIs, not an intermediate layer between NetworkManager and the kernel.

Calling ip, nft, or another CLI from a program remains useful for shell automation, but a long-running manager generally uses a library or implements the kernel protocol directly. Direct access avoids parsing command output and lets the manager subscribe to asynchronous state notifications.