18.1 Introduction
Traditionally, the Unix routing table within the kernel has been accessed using ioctl commands. In Section 17.9, we described the two commands that are provided, SIOCADDRT and SIOCDELRT, to add or delete a route. We also mentioned that no command exists to dump the entire routing table, and instead programs such as netstat read the kernel memory to obtain the contents of the routing table. One additional piece to this hodgepodge is that routing daemons such as gated need to monitor ICMP redirect messages that are received by the kernel, and they often do this by creating a raw ICMP socket (Chapter 28) and listening on this socket to all received ICMP messages.
4.3BSD Reno cleaned up the interface to the kernel's routing subsystem by creating the AF_ROUTE domain. The only type of socket supported in the route domain is a raw socket. Three types of operations are supported on a routing socket:
A process can send a message to the kernel by writing to a routing socket. For example, this is how routes are added and deleted. A process can read a message from the kernel on a routing socket. This is how the kernel notifies a process that an ICMP redirect has been received and processed, or how it requests a route resolution from an external routing process. Some operations involve both steps. For example, the process sends a message to the kernel on a routing socket asking for all the information on a given route, and the process reads back the response from the kernel on the routing socket. A process can use the sysctl function (Section 18.4) to either dump the routing table or list all configured interfaces.
The first two operations require superuser privileges on most systems, while the last operation can be performed by any process.
Some newer releases have relaxed the superuser requirement for opening a routing socket and instead restrict only routing socket messages that change the table. This allows any process to use, for instance, RTM_GET to look up a route without being the superuser. Technically, the third operation is not performed using a routing socket but invokes the generic sysctl function. We will see that one of the input parameters is the address family, which is AF_ROUTE for the operations we describe in this chapter, and the information returned is in the same format as the information returned by the kernel on a routing socket. Indeed, the sysctl processing for the AF_ROUTE family is part of the routing socket code in a 4.4BSD kernel (pp.632–643 of TCPv2). The sysctl utility appeared in 4.4BSD. Unfortunately, not all implementations that support routing sockets provide sysctl. For example, AIX 5.1 and Solaris 9 support routing sockets, but neither supports sysctl.
 |
