IPv6 Prefix Delegation

An ISP may delegate a /56, /60, or /48 to your router using DHCPv6 Prefix Delegation. The router then assigns separate /64 prefixes to LAN, Wi-Fi, server, guest, and management links. A /64 is the normal IPv6 subnet size because SLAAC and Neighbor Discovery are designed around it.

ISP
 │
 └── delegates 2001:db8:1200::/56
              │
       Saphira router
              │
      ┌───────┼────────┐
      │       │        │
    /64     /64      /64
    LAN     WiFi    Servers

A WAN interface can have one IPv6 address and still lack enough address space to number downstream networks. A delegated prefix is a routeable block with which the downstream router can advertise different /64s. Ask the ISP or inspect DHCPv6-PD state rather than inferring a prefix from one address.

Delegations have preferred and valid lifetimes. The router renews them and advertises those lifetimes downstream. If the ISP changes the prefix, old addresses eventually expire; DNS, firewall rules, VPN peers, and static service configuration must be designed for that possibility. A business may need provider-independent space or a stable tunnel/provider arrangement instead.

ip -6 addr
ip -6 route
# Inspect your DHCPv6-PD client logs with the service's normal log command
# Inspect Router Advertisements with a packet capture or RA-aware tool

Saphira must have IPv6 forwarding enabled, a WAN route, a delegated prefix, an RA service on each LAN, and nftables rules allowing only intended forwarding. The LAN clients need a return path and DNS. Do not turn on forwarding until the interfaces and allowed zones are documented.

Treat a delegated prefix as provider-controlled input. Give each LAN a documented suffix allocation, but avoid hard-coding the whole ISP prefix into every service. A provider may renew the same delegation for years, or replace it after reconnecting equipment. The routing design should recover by acquiring the new delegation, assigning its planned /64s, advertising new RA lifetimes, updating dynamic DNS where needed, and retaining a console path while the transition completes.

1. 1. Confirm what arrives on the WAN

   Inspect the DHCPv6 client state and ip -6 route. Distinguish one address on the WAN from a delegated /56, /60, or /48 that can be routed onward.

2. 2. Allocate whole /64s

   Reserve one /64 per LAN, Wi-Fi, server, guest, and management network. Record the purpose and gateway interface; do not divide an ordinary Ethernet LAN into arbitrary smaller prefixes.

3. 3. Route and advertise each LAN

   Enable IPv6 forwarding on the selected gateway, put the matching /64 on its LAN interface, send RA there, and permit only the required forward paths in nftables.

4. 4. Test a return path

   From a client, test an IPv6 destination; on the gateway use ip -6 route get for both directions. A client address alone proves neither routing nor firewall policy.

# Gateway inspection during a PD incident.
ip -6 addr
ip -6 route
ip -6 route get 2606:4700:4700::1111

# A client should see its LAN /64 and an RA default route.
ip -6 addr
ip -6 route show default

# Confirm the gateway is actually allowed to route, then inspect policy.
sysctl net.ipv6.conf.all.forwarding
nft list ruleset

• Only the WAN host has IPv6: the provider gave an address but not a useful delegated prefix, or the downstream /64 is not being advertised and routed.
• Clients have a new address after an ISP change but public DNS still points at the old prefix: update the authoritative record or use a documented dynamic-DNS process you control.
• Outbound IPv6 works but inbound services do not: that can be the intended router or host firewall policy; prove the listener and each firewall boundary before calling it a routing failure.
• A remote site loses reachability after a prefix change: update the VPN peer endpoint/allowed networks and reciprocal routes, then confirm no stale old-prefix firewall rule remains.