Operating system | Platform Linux kernel | |
Stable release 4.10.5 (2 March 2017; 20 days ago (2017-03-02)) [±] Preview release 4.11-rc3 (19 March 2017; 3 days ago (2017-03-19)) [±] Type Application programming interface License GNU General Public License | ||
Netlink socket family is a Linux kernel interface used for inter-process communication (IPC) between both the kernel and userspace processes, and between different userspace processes, in a way similar to the Unix domain sockets. Similarly to the Unix domain sockets, and unlike INET sockets, Netlink communication cannot traverse host boundaries. However, while the Unix domain sockets use the file system namespace, Netlink processes are addressed by process identifiers (PIDs).
Contents
- History
- Packet structure
- Netlink socket families
- Netlink protocols
- User defined Netlink protocol
- References
Netlink is designed and used for transferring miscellaneous networking information between the kernel space and userspace processes. Networking utilities, such as the iproute2 family and the utilities used for configuring mac80211-based wireless drivers, use Netlink to communicate with the Linux kernel from userspace. Netlink provides a standard socket-based interface for userspace processes, and a kernel-side API for internal use by kernel modules. Originally, Netlink used the AF_NETLINK socket family.
Netlink is designed to be a more flexible successor to ioctl; RFC 3549 describes the protocol in detail.
History
Netlink was created by Alexey Kuznetsov as a more flexible alternative to the sophisticated but awkward ioctl communication method which software used for setting and getting external socket options. The Linux kernel continues to support ioctl for backward compatibility. It can be used as follows:
error = ioctl(ip_socket, ioctl_type, &value_result);
Netlink was first provided in the 2.0 series of the Linux kernel, implemented as a character device. By 2013, this interface is obsolete, but still forms an ioctl communication method; compare the use of rtnetlink. The Netlink socket interface appeared in 2.2 series of the Linux kernel.
Packet structure
Unlike the BSD socket access to Internet protocols such as TCP where the headers specifying flags and destination are autogenerated, the Netlink message header (available as struct nlmsghdr) must be prepared by the caller, because the socket generally works in a SOCK_RAW-like mode, even if SOCK_DGRAM was used to create it.
The data portion then contains a subsystem-specific message that may be further nested.
Netlink socket families
The AF_NETLINK family offers multiple protocol subsets. Each interfaces to a different kernel component and has a different messaging subset. The following protocol is referenced in the field below:
int socket(AF_NETLINK, SOCK_DGRAM or SOCK_RAW, protocol)
Lacking a standard, SOCK_DGRAM and SOCK_RAW are not guaranteed to be implemented in a given Linux (or other OS) release. Some sources state that both options are legitimate, and the reference below from Red Hat states that SOCK_RAW is always the parameter, however iproute2 uses both interchangeably.
Netlink protocols
A non-exhaustive list of the supported protocol entries follows:
NETLINK_ROUTE provides routing and link information. This information is used primarily for user-space routing daemons. Linux implements a large subset of messages:
NETLINK_FIREWALL provides an interface for a user-space app to receive packets from the firewall.
NETLINK_NFLOG provides an interface used to communicate between used Netfilter and iptables.
NETLINK_ARPD provides an interface to manage the ARP table from user-space.
NETLINK_AUDIT provides an interface to the audit subsystem found in Linux kernel versions 2.6.6 and later.
NETLINK_IP6_FW provides an interface to transport packets from netfilter to user-space.
NETLINK_XFRM provides an interface to manage the IPsec security association and security policy databases - mostly used by key-manager daemons using the Internet Key Exchange protocol.
User-defined Netlink protocol
Users can add a Netlink handler in their own kernel routines. This allows the development of additional Netlink protocols to address new kernel modules.