What IPv6CP Negotiates, and What Still Needs a Prefix
A link-local address on the PPP interface is a setup step, not IPv6 access. Separate the identifier exchange from prefixes, routes and client integration.
IPv6 comes up on the PPP interface, a link-local address appears, and the change is declared finished. Then nothing routes, no global address exists, and a test to a public destination fails while the interface still looks configured. The link came up; the network never did. Work the four checks below in order and stop at the one that explains the gap.
What a link-local address actually proves
IPv6CP brings IPv6 up on the PPP link and negotiates an interface identifier for each side. That identifier produces a link-local address, which is enough to talk to the peer across the link and not enough to reach anything else. The address proves the link is ready for IPv6, and it proves nothing about the network behind the peer. Reading it as an access address is the mistake that starts most of these investigations.
The four questions below separate what the link layer settles from what the service has to supply. Answer them in order, because a later question cannot be answered while an earlier one is still open.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
Where the prefix has to come from
A global address needs a prefix from somewhere: a router advertisement, a delegated prefix, DHCPv6 or static configuration. IPv6CP does not carry one, and no amount of waiting on the link will produce one. RFC 5072 places IPv6CP as the setup step that runs before other IPv6 protocols operate on the link, which is the whole scope: preparing the link, not numbering the network. Supply the prefix and the interface starts carrying traffic instead of merely existing.
Router advertisements are the common answer on a LAN and a less reliable one on a point-to-point tunnel, because the client has to both send solicitations and accept the answer. Some tunnel clients do neither. Check what the client is willing to accept before you decide the server should send it.
The same prefix has to be reachable from the other end. A client that holds a global address but has no return path is configured, not connected.
Routes are a separate promise
Even with an address, the client needs to know which destinations belong in the tunnel, and the server needs a return path for those destinations. Those are two decisions made in two places. A tunnel that carries all IPv6 traffic needs a default route on the client and a route back on the server; a split tunnel needs both sides to agree on the same prefix list. When they disagree, traffic leaves and never returns.
Write the list down before configuring anything. If the plan says only the corporate prefix goes through the tunnel, the client should not have a default IPv6 route, and the server should not advertise one.
Client integration decides the rest
Some tunnel clients configure IPv6 explicitly. Apple's Network Extension, for example, takes an address, a prefix and a set of routes for the tunnel, so an application using it does not wait for an Ethernet-style announcement. Others rely on router advertisements arriving over the link. Both models are legitimate and they need different server behaviour, so choosing the wrong one produces a client that waits forever for a message nobody sends. Identify the model before changing the server.
An old interface name such as ppp0 proves nothing about the stack running today. A current client may use a packet-tunnel API rather than a PPP interface, and assuming it behaves like a historical connection is how a working design gets broken. Ask for the client version and the provisioning method, not the interface name.
Write the plan the client needs
A complete description covers three things: which address the client holds, which destinations the tunnel should carry, and how the network sends replies back. A link-local address answers none of them, and an accepted advertisement answers only part of one. Check each item separately rather than accepting a green indicator. Then record which mechanism supplied each answer, because that record turns the next IPv6 report into a two-minute check.
Keep the record with the service documentation and update it when the client changes. A plan that was right for a PPP client can be wrong for a packet-tunnel client on the same service. The four questions stay the same; only the answers move.