RTFM · Networking
DHCP, Router Advertisements, Prefix Delegation, and RADIUS
A Saphira network-services host can assign addresses, advertise IPv6 routing, delegate prefixes, answer local DNS, and centralise network authentication. These are infrastructure roles: build them on a documented gateway or service VLAN, not by accident on an application host.

Choose the service for each job
| Need | Component | What it does |
|---|---|---|
| IPv4 leases and simple local DNS | dnsmasq | Small-network DNS/DHCP service; use one address authority per LAN. |
| DHCPv4, DHCPv6, and Prefix Delegation | Kea | Dedicated lease and prefix-allocation service with separate DHCPv4 and DHCPv6 daemons. |
| IPv6 Router Advertisements and SLAAC | radvd | Advertises prefixes, default-router information, and RDNSS to IPv6 LAN clients. |
| Central Wi-Fi/network authentication | FreeRADIUS | Answers RADIUS requests from Wi-Fi, switches, VPN concentrators, and other RADIUS-aware equipment. |
| Recursive or authoritative DNS | Unbound, BIND, or dnsDragon | Resolve names for clients or publish names for the Internet, according to role. |
Do not run two DHCP servers on the same broadcast domain unless you have designed redundancy for it. Two independent servers can offer conflicting addresses, gateways, DNS servers, and lease state. Likewise, do not let a Wi-Fi router keep advertising IPv6 RA when Saphira is meant to be the IPv6 router for that LAN.
IPv4 DHCP: a complete small-LAN model
A DHCPv4 lease normally gives a client its IPv4 address, subnet mask, gateway, DNS server, and lease lifetime. Give servers reservations so their address is stable, but keep the reservation inside the central address plan. The server still receives a lease; it is simply offered the same planned address.
# Conceptual LAN plan
Gateway: 192.168.20.1/24
Dynamic pool: 192.168.20.100 - 192.168.20.199
Reserved edge: 192.168.20.50
DNS resolver: 192.168.20.1
# Client-side proof after receiving a lease.
ip addr show
ip route
resolvectl status 2>/dev/null || cat /etc/resolv.conf
# Release/reacquire only when you understand the impact on this host.
dhcpcd --release eno1
dhcpcd eno1The native dhcpcd syntax uses --release or -k to release an existing lease and deconfigure that interface. Do not run it over the only remote management path unless a console or independent management network exists.
// /etc/kea/kea-dhcp4.conf
{
"Dhcp4": {
"interfaces-config": { "interfaces": [ "servergw0" ] },
"lease-database": { "type": "memfile" },
"valid-lifetime": 3600,
"renew-timer": 900,
"rebind-timer": 1800,
"subnet4": [ {
"subnet": "192.168.20.0/24",
"pools": [ { "pool": "192.168.20.100 - 192.168.20.199" } ],
"option-data": [
{ "name": "routers", "data": "192.168.20.1" },
{ "name": "domain-name-servers", "data": "192.168.20.53" }
],
"reservations": [ {
"hw-address": "00:11:22:33:44:55",
"ip-address": "192.168.20.50",
"hostname": "saphira-edge"
} ]
} ]
}
}# Kea's packaged OpenRC service and configuration path.
rc-service kea-dhcp4 status
rc-service kea-dhcp4 start
rc-update add kea-dhcp4 default
# Watch the lease directory and test from one non-critical client first.
ls -la /var/lib/kea
ip addr
ip routeIPv6 requires RA as well as DHCPv6
IPv6 clients learn the default router through ICMPv6 Router Advertisements. DHCPv6 can assign addresses, DNS settings, and delegated prefixes, but it does not replace the normal RA default-route function. SLAAC lets a client form an address from the advertised /64; RDNSS can advertise DNS through RA. A production IPv6 LAN design names which of these mechanisms is used and tests real client operating systems.
# Example RA intent for a server LAN.
interface servergw0
{
AdvSendAdvert on;
AdvManagedFlag on;
AdvOtherConfigFlag on;
prefix 2a02:8012:bc57:fead::/64
{
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 2a02:8012:bc57:53a::53
{
};
};
# Inspect a client, not only the router.
ip -6 addr
ip -6 route
ip -6 neigh
tcpdump -ni servergw0 icmp6- SLAAC-only: RA provides prefix, default route, and optionally RDNSS; the client forms its address itself.
- SLAAC plus stateless DHCPv6: RA still provides the route and SLAAC address; DHCPv6 supplies extra information.
- Stateful DHCPv6: DHCPv6 supplies an address, but RA still provides the normal default-router information. The Managed and Other flags communicate the intended client behaviour.
// /etc/kea/kea-dhcp6.conf
{
"Dhcp6": {
"interfaces-config": { "interfaces": [ "servergw0" ] },
"lease-database": { "type": "memfile" },
"valid-lifetime": 3600,
"subnet6": [ {
"subnet": "2a02:8012:bc57:fead::/64",
"pools": [ { "pool": "2a02:8012:bc57:fead::100 - 2a02:8012:bc57:fead::ffff" } ],
"option-data": [
{ "name": "dns-servers", "data": "2a02:8012:bc57:53a::53" }
]
} ]
}
}rc-service kea-dhcp6 status
rc-service kea-dhcp6 start
rc-update add kea-dhcp6 default
# On a real client, prove address, RA route, DNS, and reachability separately.
ip -6 addr
ip -6 route
dig AAAA mail.example.test
ping -6 2a02:8012:bc57:fead::1Do not block ICMPv6 indiscriminately. Router Advertisements, Neighbour Discovery, and Path MTU messages are part of IPv6 operation. Filter deliberately, not by treating all ICMPv6 as unwanted noise.
Prefix Delegation turns one ISP allocation into LANs
An ISP may delegate a /56, /60, or /48 to the Saphira router. The router assigns a different /64 to each LAN, Wi-Fi, server, guest, and management link. The real Saphira reference network uses a delegated 2a02:8012:bc57::/48 and routes multiple /64s to named internal gateway interfaces. That is what turns IPv6 from a WAN address into a routed network.
ISP delegates 2a02:8012:bc57::/48
│
Saphira router
┌─────────┼────────────┐
│ │ │
:fead::/64 :db01::/64 :53a::/64
servers data nameservers
│ │ │
servergw0 datagw0 ns1gw0Keep /64 as the normal LAN size. A smaller prefix is not an IPv6 optimisation for ordinary Ethernet: SLAAC and neighbour discovery assumptions depend on /64. When an ISP changes the delegated prefix, RA preferred and valid lifetimes let clients transition, but DNS, firewall sets, VPN allowed prefixes, and static service addresses must be designed to cope with the change.
// A Kea DHCPv6 pd-pool delegates /64s from a routed /56 to downstream routers.
// This is different from a WAN DHCPv6 client requesting a prefix from an ISP.
"subnet6": [ {
"subnet": "2a02:8012:bc57:100::/56",
"pd-pools": [ {
"prefix": "2a02:8012:bc57:100::",
"prefix-len": 56,
"delegated-len": 64
} ]
} ]There are two PD directions to document. Upstream PD is the Saphira WAN router requesting a prefix from the ISP. Downstream PD is Saphira allocating pieces of a prefix it already routes to another router. Do not paste a downstream Kea pd-pool into a WAN client and expect the ISP to delegate space; confirm the WAN client's PD support and the ISP contract, then advertise the acquired /64s with RA on the downstream links.
FreeRADIUS belongs on a trust boundary
FreeRADIUS is not a Wi-Fi access point and not a substitute for firewalling. It is a central authentication service that answers RADIUS requests from equipment such as enterprise Wi-Fi, switches, and VPN systems. Place it on a protected management or services network, permit requests only from known network devices, and keep shared secrets and user identity sources out of public networks.
apk add freeradius
# OpenRC on a normal Saphira host.
rc-service freeradius status
rc-service freeradius start
rc-update add freeradius default
# Verify the configuration and logs using the installed service's own tools
# before pointing any production Wi-Fi controller or switch at it.Prove it works: Network infrastructure is behaving as infrastructure
A test client receives the intended address, route, DNS, and IPv6 information; the gateway forwards only the documented zones; and a RADIUS request succeeds only from a declared network device.