Networking

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.

Generated services

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.

per-network-interface generated services

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.

administrator-labelled generated services

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.

Standard services

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.

Plug-and-Play and dynamic configuration

Dynamically-configured networking involves starting services in response to network events sent to the Plug and Play manager.

Note: Services are not generated on the fly by the Plug-and-Play subsystem. The services to invoke must have been already generated.

Presets and static configuration

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.