Prefix delegation from the ISP — how OPNsense receives and uses the prefix

The IPv4 model gives every customer one address. The IPv6 model gives every customer a prefix — a /56, /48, or larger — that the customer subdivides for their own networks. The mechanism is DHCPv6 Prefix Delegation (DHCPv6-PD, RFC 3633). Without PD, the customer cannot route IPv6 to internal networks; with PD, the customer gets the address space they need for a real estate.

This lesson covers how OPNsense requests a delegated prefix, how it tracks the upstream prefix on LAN interfaces, and what fails when the delegation drops.

What DHCPv6-PD solves

IPv4’s “one customer, one address” model does not scale to IPv6. A customer with 5 VLANs and 200 devices needs:

• 5 prefixes (one per VLAN)
• A way to route those prefixes to the customer’s gateway
• Stable addressing that survives renumbering

The IPv6 answer: the ISP delegates a prefix — typically /56 or /48 — to the customer’s gateway. The gateway subdivides it into /64s (one per VLAN) and announces those /64s to internal hosts via SLAAC or DHCPv6. The customer owns the routing of those /64s inside their estate; the ISP only needs to route the parent prefix.

Without PD, the customer would have to ask the ISP to manually configure each prefix on each VLAN interface — operationally impossible at scale.

The IA_PD option

The DHCPv6 message that requests a prefix delegation carries an Identity Association for Prefix Delegation (IA_PD) option. The structure:

• IA_PD: a container with an ID and a set of prefixes
• IA_PD-prefix: a single prefix inside the IA_PD, with length and lifetime

The client sends an IA_PD with no prefixes (request). The server responds with an IA_PD containing one or more IA_PD-prefixes. The client receives the prefix(es), assigns them to interfaces, and routes them.

$ tcpdump -nei igb0 -vvv port 547

12:34:56.789012 2001:db8:a:b::1 > 2001:db8:a:b::2: DHCPv6, length 142
12:34:56.789012   message-type 1 (solicit)
12:34:56.789012   transaction-id 0x12345
12:34:56.789012   client-id option 1, length 14
12:34:56.789012   IA_PD option 25, length 41
12:34:56.789012     IAID: 0x00000001
12:34:56.789012     T1: 0
12:34:56.789012     T2: 0
12:34:56.789012     IA_PD-prefix option 26, length 25
12:34:56.789012       prefix: 2001:db8:abcd:e000::/56
12:34:56.789012       preferred-lifetime 604800
12:34:56.789012       valid-lifetime 2592000

Configuring OPNsense to request PD

The WAN-side DHCPv6 client is configured under Interfaces → [WAN] → IPv6 Configuration Type: DHCPv6. The relevant fields for PD:

• Request a prefix delegation: yes (default for most ISPs).
• Prefix delegation size: typically /56 or /48; the ISP determines this and the operator cannot change it.
• Send a hint: an optional IA_PD hint; the ISP may or may not honour it. Used by operators who want a specific prefix and the ISP is willing to honour a hint.

After applying, the WAN interface negotiates with the ISP and receives:

1. An IA_NA (single address for the WAN interface itself, typically from the ISP’s /64).
2. An IA_PD (delegated prefix for downstream).

The firewall stores both. The IA_NA becomes the WAN interface’s IPv6 address; the IA_PD becomes the basis for downstream LAN prefixes.

Track interface — deriving LAN prefixes

The most common production setup: LAN interfaces use “track interface” mode, which means “derive my IPv6 address from the prefix on the upstream interface”. For a /56 delegation:

• Delegated prefix: 2001:db8:abcd:e000::/56
• LAN track interface with prefix ID 0: derives 2001:db8:abcd:e000::/64
• DMZ track interface with prefix ID 1: derives 2001:db8:abcd:e100::/64
• Guest track interface with prefix ID 2: derives 2001:db8:abcd:e200::/64

The prefix ID is the low byte of the sub-prefix. For a /56, the low byte is fully under operator control; for a /60, only the low 4 bits (16 subnets).

The configuration is under Interfaces → [LAN] → IPv6 Configuration Type: Track Interface:

• Track IPv6 interface: WAN (or whichever interface has the PD).
• IPv6 prefix ID: the sub-prefix byte.

After applying, the LAN interface has an IPv6 address in the derived prefix, and the RA service on the LAN advertises that prefix. Hosts on the LAN self-configure via SLAAC.

What happens when the prefix changes

ISPs rotate delegated prefixes for several reasons:

• DHCPv6 lease expiry. The T1/T2 lifetimes trigger a re-negotiation.
• ISP-side policy. Some ISPs rotate prefixes on a schedule.
• Equipment change at the ISP. A new BRAS, a new DHCPv6 server, a new policy.

When the prefix changes, OPNsense detects the change (the dhcp6c client receives a new IA_PD) and re-derives the LAN prefixes. The track-interface mechanism updates:

1. The LAN interface’s IPv6 address (the firewall’s address on the LAN).
2. The RA service on the LAN (so it advertises the new prefix).
3. The host routes for the new prefix.

The change is atomic from the LAN host’s perspective: the LAN prefix appears with a new identity. Hosts that were using SLAAC addresses in the old prefix will eventually migrate; hosts that had stable addresses via stateful DHCPv6 get a new one.

Common PD failure modes

Four failure modes appear repeatedly:

1. No PD received on the WAN. The ISP does not delegate, or the firewall is not configured to request. Verify with ifconfig <wan> (look for IA_NA only, no IA_PD); fix by enabling “Request a prefix delegation” in the WAN config.

2. PD received but LAN interfaces do not track it. The track-interface is set to a different upstream interface. Verify with ifconfig <lan> (the LAN address is in a prefix unrelated to the WAN’s delegated prefix); fix by aligning the track-interface upstream.

3. PD received but RAs on the LAN do not advertise the new prefix. The RA service is configured with a static prefix that does not match the track-interface’s derived prefix. The RAs are flowing but carry the wrong prefix. Fix: align the RA configuration with the track-interface derived prefix (or use the radvd auto-config mode that follows the interface address).

4. PD changes and LAN clients lose connectivity. The track-interface mechanism updated the firewall’s address, but the host routes are stale or the SLAAC clients have not re-configured. Verify by capturing RAs on the LAN (tcpdump -nei <lan> icmp6 and 'ip6[40]==134'); fix by waiting for the next RA cycle or rebooting the LAN client.

Verification

After configuring PD, the verification steps:

# On the firewall
ifconfig <wan> | grep inet6          # IA_NA + IA_PD
ifconfig <lan> | grep inet6          # Derived LAN prefix
rtsol -d <lan>                        # Confirm RA carries the LAN prefix

# On a LAN client
ping6 2001:db8:abcd:e000::1           # Ping the firewall LAN gateway
ping6 2001:4860:4860::8888            # Ping Google DNS over IPv6

If the firewall has a delegated prefix and the LAN client can ping the firewall’s LAN address but cannot reach external IPv6, the issue is upstream routing or the firewall’s outbound NAT for IPv6 (which most deployments disable — IPv6 hosts typically have end-to-end connectivity).

Summary

• DHCPv6-PD is how ISPs delegate a prefix (typically /56 or /48) to a customer.
• OPNsense requests PD on the WAN interface via the dhcp6c client.
• Track-interface mode derives LAN prefixes from the delegated prefix using a configurable sub-prefix ID.
• ISP prefix rotation triggers a re-derivation; LAN interfaces pick up the new prefix automatically.
• Bind internal services to ULAs to insulate them from prefix rotation.
• Verify with ifconfig, rtsol, and tcpdump icmp6 ra on the LAN.