# 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.

- 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 NetBSD the Plug and Play manager is `devpubd`. There are as yet no supplied configuration files for linking it to the network services.

- 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.

## 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.