IPv6 in an MPLS VPN: Three Choices, Not One Address Family
Customer VPN routes, the PE-to-PE BGP session and the core transport are separate decisions. A session can run one family while carrying another.
Say "run an IPv6 L3VPN over IPv6 BGP" in a design review and three separate decisions hide inside that one sentence. Which prefixes belong to the customer's VPN, which addresses carry the routing session between the provider edges, and which core moves the labelled packet are independent choices. They can all be IPv6, they can be mixed, and mixing them is allowed on purpose. Untangling the three is what turns a vague requirement into something a platform can be tested against.
Separate the three jobs
The first job is the customer route: IPv6 prefixes that belong to one VPN routing context and must stay out of every other context. The second is the routing connection between the provider edge routers that exchange those prefixes. The third is the transport that carries the labelled customer packet across the core to the remote edge. Naming only one of them is not a design yet.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
Each job owns its own address family, its own failure modes and often its own team. The table is useful precisely because a single sentence in a design document tends to collapse all three rows into one.
The route family is VPN-IPv6, not IPv6 unicast
RFC 4659 defines the BGP/MPLS IPv6 VPN family, and membership in it is more specific than the word IPv6 suggests. A route there is a route distinguisher joined to an IPv6 prefix, encoded under AFI 2 and SAFI 128. Ordinary IPv6 unicast is a different family, so an advertisement that looks like a prefix in a looking glass may not be the same object at all. Misreading the family is the first way this design goes wrong.
The difference bites at the edge, where a route has to land inside the right VPN context before it does anything. Receiving a prefix proves the exchange happened and says nothing about installation. That gap produces the classic report where the session is up and the customer is still dark.
The session may run a different family than the VPN
Nothing forces the BGP connection between two edges to use the VPN's own family. The specification permits an IPv4 or an IPv6 session, and IPv6 VPN transport is itself defined over both core types. An IPv6 session therefore says nothing about the family of what it carries, and it does not pick the data plane either. Three independent bits, and the design should carry all three separately.
That is freeing and easy to misread in the same breath. IPv6 customer routes can ride an IPv4-addressed session, and IPv4 routes can ride an IPv6 one, provided the platform supports the combination and the next hop resolves. What must not happen is letting the session imply the payload, in the design document or in the monitoring that proves the service later.
Next hop on an IPv4 core has its own encoding
When the core under the VPN is IPv4, the route does not show up with a next hop the ingress edge can use directly. It arrives in IPv4-mapped IPv6 form, which is how the specification expresses the egress edge when the transport below is IPv4. The ingress router then has to turn that mapped address into something it can actually reach across the core, and resolution is the step that quietly fails.
Read it as a forwarding dependency rather than a string to copy between devices. Confirm three things on the platform you actually run: the advertised next hop resolves to a usable path, the label stack is accepted, and the destination lands in the intended VPN context. Any one of those failing leaves a session that looks healthy and forwards nothing, which is why the check belongs in the acceptance run rather than in a later incident.
Write the requirement in four lines
A requirement worth testing names four things: the VPN family, the session transport, the next-hop encoding and the core arrangement. It then names one customer prefix to follow end to end, through exchange, installation, label resolution and return path. "Supports IPv6 BGP" covers none of the four and hides where the mismatch actually lives.
A healthy session without the VPN-IPv6 exchange is incomplete, and a received VPN route without working forwarding is equally incomplete. Keeping those as separate acceptance lines makes the next troubleshooting conversation short, because the failing line is already written down.