IPv6 over VPN: a delegated prefix is not an address pool

Two requests arrive on the same day: a laptop needs IPv6 over the tunnel, and a small site wants IPv6 for the devices behind its router. Both get answered with an address, and the second one then spends a week failing. The roles differ, and so do the mechanisms, the configuration and the check that proves it works. This runbook keeps them apart.

Step one: decide which role you are serving

A single host needs one address on its tunnel interface, with a route to the far side and nothing downstream to number. A router behind the tunnel needs a whole network that it can hand out, plus a route on the far side that points those addresses back to it. What sits behind the tunnel drives every decision that follows.

Answer that question before opening any configuration. Everything after this step depends on which answer you gave.

Step two: address assignment for a single host

Assign the tunnel address, confirm the prefix length the product expects, and check that the client installs a route for the remote range rather than sending it to the local default gateway. A /128 on a tunnel interface is normal for a point-to-point link, while a /64 there claims a network nobody delegated. Two outputs settle the question: the address table and the route table, read at both ends. Read them together, because a route pointing at the wrong interface is the most common mistake at this step.

Verify with the address and route tables on both ends, then send one request. If the request leaves correctly and nothing comes back, the fault sits in the far side's route rather than the client's address.

Step three: delegation for a router behind the tunnel

Prefix delegation is a separate mechanism from address assignment, with its own request and its own lease. The delegating side has to be configured to hand out a prefix large enough for the downstream network, and the requesting router has to number its inside interface from that prefix.

Do not assume the pool that serves mobile clients can delegate. Many VPN products assign single addresses and have no delegation role at all, and a provider prefix that arrives at your edge is not automatically passed to a peer. Record which role each pool serves, because the two are configured in different places.

Step four: make the return route explicit

Both ends must agree which peer carries which prefix. On the far side, add the route for the delegated network pointing at the tunnel, and confirm that no overlapping range already claims it.

A valid prefix with no return route produces a tidy addressing plan and no connectivity. A route without an access rule exposes more of the site than intended, so pair the two changes in the same window and keep a half-applied state away from users.

Step five: verify from behind the router

Run the checks in order: the tunnel interface address on the client, the delegated prefix on the inside interface, the far-side route toward that prefix, and finally a request from a device behind the router. Use a destination you control so a silent block is distinguishable from a missing route. Whichever step surprises you is the one to fix before moving on.

Do the last check twice, once from the router itself and once from a device behind it. A router that can reach the destination while its clients cannot is a delegation or forwarding problem, not an upstream one.

Rollback

Keep the previous addressing configuration before the change, and note which of the two mechanisms you altered. Removing a delegated prefix without removing the route leaves a black hole, and removing the route without the prefix leaves addresses that nothing can reach. Note the two changes separately, since undoing one while leaving the other makes a site unreachable in one direction only.

If a product turns out not to support the role you need, stop and change the design rather than stretching a client field to hold a range it was never meant to hold. A support case answered with the wrong mechanism costs more than the design change would have.