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@namedhclient@nameudhcpc@namedhcpcd@namehostap@namewpa@nameppp@namesppcontrol@namerfcomm_pppd@namesnort@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@labelstatic_ndp@labelThese 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@labelstatic_ip6@labelThese 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@_v4mappedThis ensures that IPv4-mapped IPv6 addresses, 0::FFFF:0:0/96, are not routed.
static_ip6@_v4compatThis ensures that IPv4-compatible IPv6 addresses, 0::0000:0:0/96, are not routed.
static_ip6@_llaThis ensures that link-local unicast addresses, FE80::/10, are not routed. (Note that site-local addresses, FEC0::/10, are routable.)
static_ip6@_ilmaThis ensures that interface-local multicast addresses, FF01::/16, are not routed.
static_ip6@_llmaThis ensures that link-local multicast addresses, FF02::/16, are not routed.
static_ip6@_6to4llaThis ensures that 6to4-mapped link-local unicast IPv4 addresses, 2002:A9FE::/32, are not routed.
static_ip6@_6to4ilmaThis ensures that 6to4-mapped link-local multicast IPv4 addresses, 2002:E000::/20, are not routed.
static_ip6@_6to4llmaThis ensures that 6to4-mapped interface-local IPv4 addresses, 2002:7F00::/24, are not routed.
static_ip6@_6to4cnaThis ensures that 6to4-mapped current-network IPv4 addresses, 2002:0000::/24, are not routed.
static_ip4@_llaThis ensures that link-local unicast IPv4 addresses, 169.254.0.0/16, are not routed.
static_ip4@_llmaThis ensures that link-local multicast IPv4 addresses, 224.0.0.0/4, are not routed.
static_ip4@_llmaThis 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.