Who Stole My /56? Chasing IPv6 Prefix Delegation Across UK ISPs

There's a particular flavour of disappointment that comes from plugging a freshly built Linux router into a UK fibre line, watching it pick up an address, and then discovering the ISP will only delegate a single /64 — which you must now hand entirely to one VLAN, or paper over with NAT66 and a sense of shame. That's the postcode lottery.

/64 is not a prefix, it's a taunt

IPv6 gives you 64 bits of host space per subnet. You do not want one subnet. You want a management LAN, a trusted LAN, an IoT VLAN, a guest network, and something separate for the containers. That's five before breakfast. Anyone running a homelab will find ten without trying.

The working assumption should be a /56 — 256 /64s — or a /48 if your ISP is generous. A /64-only delegation means the provider has effectively rebuilt IPv4 NAT with more characters, and it usually means the supplied CPE was never expected to hand a prefix downstream.

What the providers actually do

Treat the following as reported behaviour, not a specification. The size you get depends on your exchange, the BNG, the CPE and possibly the phase of the moon.

• BT and EE FTTP: a /56 is typical, requested by the CPE. The Smart Hub won't pass one to a device behind it, so replacing it with your own gateway is the usual route to more than one subnet.
• Virgin Media: /56 across most DOCSIS areas, with the hub in modem mode doing the decent thing. Some areas renumber on reboot.
• Sky: historically /56, rolled out area by area, with some exchanges lagging behind others.
• TalkTalk: genuinely mixed — /48 in places, /64-only or nothing in others.
• Zen: business-grade, /48 available on request, prefix stays put.
• Andrews & Arnold: will do a /48 if you ask, and document it, which is more than most manage.
• CityFibre altnets and their retail partners: the wild west. Some /56, some /64, some still "on the roadmap".
• Mobile and fixed wireless: usually a /64, often behind CGNAT, occasionally no delegation at all.

Openreach FTTP itself is neutral in all this. The delegation size is whatever the ISP configures on its BNG and what its DHCPv6 server is willing to hand out — which is why two neighbours on the same street can get completely different answers.

Testing your own line

Start with dhcpcd, which is the most transparent about what it asked for and what it received.

interface wan0
    ia_pd 1 lan0
    noipv6rs

interface lan0
    ia_pd 1/0/0
    noipv6rs

ia_pd 1 lan0 requests a prefix and binds it to the LAN interface; the /0/0 on the LAN side is the subnet-ID offset. Run dhcpcd -dB wan0 to see the DUID and the whole IA_PD exchange in detail.

On systemd-networkd, the same thing looks like this:

# /etc/systemd/network/10-wan.network
[Network]
DHCP=ipv6

[DHCPv6]
PrefixDelegationHint=::/56

# /etc/systemd/network/20-lan.network
[Network]
IPv6SendRA=yes
DHCPPrefixDelegation=yes

[DHCPPrefixDelegation]
UplinkInterface=wan0
SubnetId=0x01

Then watch the wire while it happens:

tcpdump -i wan0 -nv 'udp port 546 or udp port 547 or icmp6'

You're looking for a Solicit, an Advertise carrying an IA_PD option, and a Reply with a delegated prefix. If you see the IA_PD going out and a Reply coming back with NoPrefixAvail, that's your answer — and it's the ISP's answer, not yours. A Wireshark capture filtered on dhcp6.client-pd shows the same thing with nicer colours.

Sanity checks afterwards: ip -6 route show, networkctl status lan0, and rdisc6 lan0 to confirm your RAs look sensible. If clients get an address but no DNS, you're advertising RA options that never arrived.

The gateway bits everyone forgets

Turning on forwarding is one line, but the consequences aren't: net.ipv6.conf.all.forwarding=1 and net.ipv6.conf.wan0.accept_ra=2, because a forwarding router ignores RAs by default and you will otherwise spend an evening wondering why the prefix quietly disappears after a reboot.

Then the firewall. A blanket drop of ICMPv6 is the classic own goal — you need neighbour discovery (types 133–136) and Packet Too Big (type 2), or you get half-broken connections where the handshake completes and nothing else does. In nftables, use the inet family and match on interface rather than hardcoded addresses, because the prefix will change:

nft add rule inet filter forward iifname "wan0" ct state established,related accept

If you're on PPPoE, remember the MTU is 1492, and clamp MSS on the LAN side or watch large transfers stall. tcp flags syn tcp option maxseg size set rt mtu in the forward chain sorts it. And if the ISP router is still sitting in the path, check it isn't also sending RAs — two RA sources on one segment is a creative way to lose a Saturday.

Renumbering, and the reverse DNS nobody offers

Dynamic prefixes mean your AAAA records rot. Run a DDNS client that fires on a prefix change event rather than a timer — watch the netlink event, or hook into dhcpcd — otherwise you'll be publishing yesterday's address for hours. If you host anything public, ask about delegation of the matching ip6.arpa zone. Few residential ISPs do it, but you should know the answer before you plan around it.

What to ask before you commit

Ring or email sales and put it in writing:

1. Do you delegate a prefix over DHCPv6-PD, and what size?
2. Is it stable across reboots and reconnects, or does it change?
3. Will you delegate to a customer-supplied router rather than your CPE?
4. Does it work over PPPoE, and what MTU do you use?
5. Do you permit inbound connections on 80 and 443, and what does the AUP say?
6. Do you delegate reverse DNS for the prefix?

If the answer to the first question is "a /64", you've learned something valuable before spending any money. IPv6 in the UK is genuinely better than it was, but it remains a per-exchange, per-ISP, per-router experience — and the only reliable way to know what you've been given is to capture the packets yourself.