A prefaratory note on the terminology used here: Configuration and address assignment are two different things. The difference between dynamic configuration and static configuration lies in whether the interface is configured in response to Plug and Play events or unconditionally at system bootstrap/shutdown. The difference between dynamic address assignment and static address assignment is whether the IP address(es) are hardwired into the configuration or obtained at runtime by a DHCP client/assigned by stateless auto-configuration.
The nitty-gritty of managing network configuration is done with two suites of services, that are generated from templates based upon a parameter. They are individually preset and disabled in accordance with how the various network interfaces and static networking table entries are intended to be configured.
The first suite is grouped by name, the name of a network interface:
ifscript@name
A service that does not have a long-running dæmon process, that runs /etc/start_if.name
and /etc/stop_if.name
scripts at start and stop.
These are the first and last things that are run for the interface.
ifconfig@name
A service that does not have a long-running dæmon process, that runs ifconfig
with various options for link-level, IPv4, and IPv6 settings, at start and stop.
This is the service that configures and deconfigures statically-assigned IPv4 and IPv6 addresses, and link-level (MAC) addresses.
natd@name
dhclient@name
udhcpc@name
dhcpcd@name
hostap@name
wpa@name
ppp@name
sppcontrol@name
rfcomm_pppd@name
snort@name
These services have a long-running dæmon process; natd
, dhclient
, udhcpc
, dhcpcd
, hostap
, hostap
, wpa
, pppd
, sppcontrol
, rfcomm_pppd
, and snort
respectively.
They are ordered to start after ifconfig@name
has started and to stop before it is stopped, but they are not ordered relative to one another.
One does not, of course, run all of these services; only some of them. For starters, one generally only wants one of the DHCP clients to be running, for an individual interface, at a time.
The second suite is grouped by an arbitrary label label:
static_arp@label
static_ndp@label
These services do not have a long-running dæmon process, but at start and stop set up and tear down static entries in the IPv4 and IPv6 ARP and NDP tables.
static_ip4@label
static_ip6@label
These services do not have a long-running dæmon process, but at start and stop set up and tear down static IPv4 and IPv6 routing table entries.
Conventionally, there are some services in this set that set up routing that all systems are supposed to have:
static_ip6@_v4mapped
This ensures that IPv4-mapped IPv6 addresses, 0::FFFF:0:0/96, are not routed.
static_ip6@_v4compat
This ensures that IPv4-compatible IPv6 addresses, 0::0000:0:0/96, are not routed.
static_ip6@_lla
This ensures that link-local unicast addresses, FE80::/10, are not routed. (Note that site-local addresses, FEC0::/10, are routable.)
static_ip6@_ilma
This ensures that interface-local multicast addresses, FF01::/16, are not routed.
static_ip6@_llma
This ensures that link-local multicast addresses, FF02::/16, are not routed.
static_ip6@_6to4lla
This ensures that 6to4-mapped link-local unicast IPv4 addresses, 2002:A9FE::/32, are not routed.
static_ip6@_6to4ilma
This ensures that 6to4-mapped link-local multicast IPv4 addresses, 2002:E000::/20, are not routed.
static_ip6@_6to4llma
This ensures that 6to4-mapped interface-local IPv4 addresses, 2002:7F00::/24, are not routed.
static_ip6@_6to4cna
This ensures that 6to4-mapped current-network IPv4 addresses, 2002:0000::/24, are not routed.
static_ip4@_lla
This ensures that link-local unicast IPv4 addresses, 169.254.0.0/16, are not routed.
static_ip4@_llma
This ensures that link-local multicast IPv4 addresses, 224.0.0.0/4, are not routed.
static_ip4@_llma
This ensures that interface-local IPv4 addresses, 127.0.0.0/8, are not routed.
Various other parts of the system match up with these.
The tinydns
service by default is set up to publish reverse lookups for these IP address ranges.
The ip6addrctl
service sets an explicit address selection policy for these address ranges.
All of the generated services have a wanted-by/
relationship to the static-networking
target (which has the alias name networking
on Linux operating systems).
This is a standard target, that is in turn wanted by the normal
target.
The network-interfaces
service no longer has any function.
Its old purpose was to run the ifup -a
and ifdown -a
commands on Linux operating systems.
Not only are these commands not necessarily available across all such operating systems, but the functionality of those commands is now superseded by the aforementioned suites of generated services.
ifup
and ifdown
essentially do the same task as them, but badly.
ifup
and ifdown
run most of the same programs, DHCP clients and commands to set up and tear down IP address configuration; but they do not run the long-running dæmons under proper service management.
The network-runtime
service handles the creation and destruction of the /run/network
runtime directory that various other services use.
Dynamically-configured networking involves starting services in response to network events sent to the Plug and Play manager.
On FreeBSD the Plug and Play manager is devd
and the link from the Plug and Play manager to the network services is the /usr/local/etc/devd/netif-nosh.conf
configuration file.
This configuration file specifies various events that will start the ifscript@name
, ifconfig@name
, and dhclient@name
services for an interface.
On Linux operating systems, the Plug and Play manager can be eudev
, Busybox mdev
, Suckless mdev
, systemd-udev
, mdevd
, or vdev
.
There are as yet no supplied configuration files for linking them to the network services.
Note: Services are not generated on the fly by the Plug-and-Play subsystem. The services to invoke must have been already generated.
As mentioned, static-networking
is a standard target, that is in turn wanted by the normal
target.
Thus individual generated networking services can be enabled so that they are automatically started at bootstrap.
This is "static" inasmuch as what services are started is irrespective of Plug and Play events.
It is a good idea to preset, rather than directly enable, the services.
The 90-bsd-static-networking
and 90-linux-static-networking
preset files govern presetting services, and limit by default what networking services will be enabled (by presetting) on a platform.
For example: The presets prevent natd@name
and sppcontrol@name
generated services from being enabled (by presetting) on non-BSD platforms that do not have these dæmons.
Whilst one can generate such services in other ways, it is commonly the case that generated services are created by the external configuration import subsystem in response to networking configuration settings that it reads from rc.conf
.
These settings determine the list of network interfaces to generate services for (network_interfaces
), settings for things like the ifconfig@name
services (ifconfig_name
et al.), and the name of the DHCP client to use (dhclient_program
).
They may, in their turn, be derived from other things as part of rc.conf
amalgamation.