DEV Community

IPYE
IPYE

Posted on AI-assisted

DHCPv6 Prefix Delegation Explained: How a Router Gets Its Own IPv6 Prefix

#ipv6 #networking #dhcp #linux

Disclosure up front: I run IPYE, a company that leases IP space. It gets one short paragraph at the end; the rest is plain networking.

With IPv4, a small-office router usually gets one address and uses NAT for everything behind it. With IPv6, the provider hands the router a whole prefix, which the router subdivides among its internal networks. The standard mechanism is DHCPv6 Prefix Delegation (DHCPv6-PD), defined in the DHCPv6 specification, RFC 8415, which obsoleted the original RFC 3633 for this purpose. This article explains the roles, the message exchange, and the points where it commonly fails. Examples use 2001:db8::/32.

The roles

  • Delegating router: the provider-side device (often a BNG or an edge router) that owns a pool of prefixes and hands them out.
  • Requesting router: the customer's router, which asks for a prefix and then uses it on its own downstream interfaces.

Delegation is a lease, not a gift: the prefix has lifetimes, and the delegating router remembers which client holds it. Delegated sizes vary by provider (/48, /56, /60 and /64 all occur), and the requesting router can include a hint of the length it wants, which the server is free to ignore. A /64 delegation leaves room for only one downstream network.

The message exchange

DHCPv6 clients use UDP port 546 and servers and relays use UDP port 547. The client begins by sending to the link-local multicast address ff02::1:2 (All_DHCP_Relay_Agents_and_Servers). The four-message exchange is:

Message Direction Purpose
Solicit client to server "Is any delegating router there?" It carries an IA_PD option, which is the request for a prefix
Advertise server to client Offers a prefix, with lifetimes
Request client to server Asks for the offered prefix from a chosen server
Reply server to client Confirms; the client now holds the prefix

RFC 8415 also defines a two-message variant using Rapid Commit. Afterwards the client uses Renew (extend the lease with the same server), Rebind (ask any server) and Release (give the prefix back). The option that carries the prefix is IA_PD, which contains one or more IAPREFIX entries with the prefix, its length and two lifetimes:

  • Preferred lifetime: how long the prefix should be used for new communication.
  • Valid lifetime: how long it remains usable at all.

The IA_PD also carries timers T1 and T2 which tell the client when to try Renew and Rebind respectively. If the client cannot renew before the valid lifetime ends, it must stop using the prefix.

What happens after the prefix arrives

Receiving a prefix does not configure anything by itself. The requesting router must then:

  1. Split the delegated prefix into /64s, one per downstream interface (a /56 yields 256, a /60 yields 16).
  2. Assign an address to each downstream interface from its /64.
  3. Advertise each /64 to its LAN with Router Advertisements (RFC 4861) so hosts can use SLAAC (RFC 4862), or run a DHCPv6 server for stateful addressing.

Hosts on those LANs never see DHCPv6-PD; they see ordinary Router Advertisements. The requesting router also needs its own WAN-side address and default route, and DHCPv6 does not provide a default gateway: that comes from a Router Advertisement on the WAN link, while the WAN address may come from SLAAC or a DHCPv6 IA_NA request. RFC 7084 lists these behaviours for IPv6 customer edge routers.

The M and O flags in Router Advertisements

Router Advertisements carry two flags: M ("managed address configuration") says to use DHCPv6 for addresses, and O ("other configuration") says to use DHCPv6 for other information such as DNS servers. They do not control prefix delegation. A requesting router asks for a prefix because it is configured to, not because of an RA flag, so a missing M or O flag is not the explanation if PD fails.

The routing step that is easy to miss

The delegating router must be able to send traffic for the delegated prefix to the requesting router. That requires a route: delegated prefix, next hop the client's link-local (or WAN) address. Some servers install it automatically; others rely on a script, a relay, or a manual static route. If a client holds a prefix but nothing outside can reach hosts in it, check for this route first. Equally, the requesting router must not send unused parts of the delegated prefix back out its WAN, or traffic may loop; many CE routers install an unreachable route for the whole prefix, with more specific routes for the subnets in use.

A configuration example (systemd-networkd)

With systemd-networkd, the WAN side requests a prefix and the LAN side receives a subnet of it. The exact option names have changed between releases, so check the documentation of your version:

# /etc/systemd/network/10-wan.network
[Match]
Name=wan0
[Network]
DHCP=ipv6
IPv6AcceptRA=yes

# /etc/systemd/network/20-lan.network
[Match]
Name=lan0
[Network]
DHCPPrefixDelegation=yes
IPv6SendRA=yes
Enter fullscreen mode Exit fullscreen mode

Other clients, such as dhcpcd or wide-dhcpv6-client, use different syntax; on the server side, ISC Kea supports prefix delegation pools.

Debugging

  • Capture the exchange: tcpdump -ni wan0 'udp port 546 or udp port 547'. You should see Solicit, Advertise, Request, Reply. If you see only Solicit, nothing is answering on that link.
  • If Advertise arrives with a status code other than success inside the IA_PD, such as NoPrefixAvail, the server has no prefix to give or the request does not match its configuration.
  • Check what you hold with ip -6 addr and ip -6 route.
  • If hosts have addresses but no connectivity, test routes in both directions and check that the firewall allows DHCPv6 and ICMPv6.
  • Prefixes can change when a lease lapses or a link is reset, depending on the provider's policy. A server may, but need not, hand the same prefix back to a returning client, so do not hard-code delegated prefixes into DNS or firewall rules.

Summary

The common failure points are a delegated prefix too small for the networks you need, a missing route on the delegating side, and renewal problems when the WAN link flaps.

About IPYE

IPYE (https://my.ipye.com) leases IPv4, IPv6, and ASN space; a /48 IPv6 block is free for the first year. LOA, ROA, rDNS, and WHOIS are handled by IPYE. Locations: Los Angeles, New York, Ashburn, Salt Lake City, London, Amsterdam, and Frankfurt. Questions: ipye@turnel.com.

Disclosure: I run IPYE

Top comments (0)