AF_NETLINK sockets allow one to enumerate networking stack elements, and subscribe to events regarding changes, additions, and deletions thereof. Netlink is kind of a pain in the ass to work with directly, though. My libnetlink enumerates all existing networking stack elements, subscribes to events, and makes all of this available to the user via queries and/or realtime callbacks. libnetstack has been designed to provide responsive service even in the presence of millions of routes with rapid churning of the route tables.
Code lives at https://github.com/dankamongmen/libnetstack.
rtnetlink(7) (originally implemented AFAIK by Alexey Kuznetsov, the Mad Russian, whom I haven't seen post to LKML in many years, and miss) provides the NETLINK_ROUTE protocol for the AF_NETLINK family of sockets. According to netlink(7),
Netlink is a datagram-oriented service. Both SOCK_RAW and SOCK_DGRAM are valid values for socket_type. However, the netlink protocol does not distinguish between datagram and raw sockets."—netlink(7), Linux man pages 5.03
Creating and using such a socket does not require any special permissions, though CAP_NET_ADMIN is needed for many control messages (verified kernel-side, of course). Once established, we can directly request dumps of networking stack state with the RTM_GET* set of messages, and/or simply subscribe to the appropriate multicast groups, sit back, and let new events roll to us.
|RTNLGRP_IPV4_IFADDR||RTM_NEWADDR, RTM_DELADDR (AF_INET only)|
|RTNLGRP_IPV6_IFADDR||RTM_NEWADDR, RTM_DELADDR (AF_INET6 only)|
|RTNLGRP_IPV4_ROUTE||RTM_NEWROUTE, RTM_DELROUTE (AF_INET only)|
|RTNLGRP_IPV6_ROUTE||RTM_NEWROUTE, RTM_DELROUTE (AF_INET6 only)|
- "The Netlink protocol: Mysteries Uncovered", Jan Engelhardt 2010-10-30