MPLS L3VPN: 6VPE - IPv6 VPN over MPLS
As we saw on the 6PE post, 6PE allows a service provider to transport global IPv6 traffic over an existing IPv4/MPLS core. However, enterprises and service providers usually need more than global reachability: they need traffic isolation per customer and support for overlapping address spaces, which are the same requirements that MPLS L3VPN already solves for IPv4. The IPv6 version of that solution is 6VPE (IPv6 VPN Provider Edge), defined in RFC 4659.
6VPE extends the MPLS L3VPN model to IPv6. The PEs keep the customer IPv6 routes inside VRFs and exchange them through MP-iBGP using a new address-family called VPNv6, while the core stays IPv4-only. The P routers don’t need a single line of IPv6 configuration; they just label-switch packets between the PEs, exactly as they do for VPNv4.
The mechanics are almost the same as the ones explained in the MPLS L3VPN post, with two particular details for IPv6:
- VPNv6 address: it is built by prepending the 8-byte Route Distinguisher (RD) to the 16-byte IPv6 prefix, resulting in a unique 24-byte prefix. This is what allows overlapping IPv6 address spaces between customers.
- IPv4-mapped next hop: since the BGP sessions and the core transport are IPv4, the next hop of a VPNv6 route is encoded as an IPv4-mapped IPv6 address (for example ::FFFF:3.3.3.3). The ingress PE resolves that address to the IPv4 loopback of the egress PE and to the LDP label that reaches it.
The control plane and data plane work as follows:
- Control plane: the CE exchanges native IPv6 routes with the PE (in this lab, with EIGRPv6) inside the VRF. The PE converts these prefixes into VPNv6 routes, assigns a VPN label to each one, and advertises them over the iBGP VPNv6 session. In this scenario the P router acts as Route Reflector, so each PE only peers with it.
- Data plane: the ingress PE imposes a two-label stack. The outer label is the transport label learned via LDP, used to reach the loopback of the egress PE across the IPv4 core. The inner label is the VPN label assigned via MP-BGP, used by the egress PE to identify the VRF and the outgoing interface.
Demonstrating: 6VPE
The scenario uses five routers and the following design:
- IPv4 core: PE1 (1.1.1.1), P (2.2.2.2) and PE2 (3.3.3.3) run OSPF area 0 and LDP. The links are 10.1.2.0/24 (PE1-P) and 10.2.3.0/24 (P-PE2). There is no IPv6 in the core.
- Route Reflector: the P router is the RR for the VPNv6 address-family. The PEs establish the iBGP session only with 2.2.2.2.
- Customer VRF: a VRF named CERC with RD 3549:1 and route-target 3549:1 on both PEs.
- PE-CE routing: EIGRPv6 autonomous system 10. CE1 connects to PE1 over 2001:db8:12::/64 and CE2 connects to PE2 over 2001:db8:23::/64. The loopbacks 2001:db8:1::1/128 (CE1) and 2001:db8:2::2/128 (CE2) are the prefixes that will travel through the VPN.
P (core router and Route Reflector)
The P router works only with IPv4 for transport, but its BGP process reflects the VPNv6 address-family between the two PEs.
hostname P
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Ethernet0/0
ip address 10.1.2.2 255.255.255.0
mpls ip
!
interface Ethernet0/1
ip address 10.2.3.2 255.255.255.0
mpls ip
!
mpls ldp router-id Loopback0
!
router ospf 1
network 2.2.2.2 0.0.0.0 area 0
network 10.1.2.0 0.0.0.255 area 0
network 10.2.3.0 0.0.0.255 area 0
!
router bgp 3549
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 3549
neighbor 1.1.1.1 update-source Loopback0
neighbor 3.3.3.3 remote-as 3549
neighbor 3.3.3.3 update-source Loopback0
!
address-family vpnv6
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
neighbor 1.1.1.1 route-reflector-client
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
neighbor 3.3.3.3 route-reflector-client
exit-address-family
!
PE1
On PE1 we define the VRF CERC, enable EIGRPv6 on the PE-CE link inside the VRF, and configure the mutual redistribution between EIGRPv6 and BGP. Note that VRF-aware EIGRPv6 is only supported with EIGRP named mode, the same configuration style used on the MPLS L3VPN post for IPv4.
hostname PE1
!
ipv6 unicast-routing
!
vrf definition CERC
rd 3549:1
!
address-family ipv6
route-target export 3549:1
route-target import 3549:1
exit-address-family
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Ethernet0/0
description Link to P
ip address 10.1.2.1 255.255.255.0
mpls ip
!
interface Ethernet0/1
description Link to CE1 (VRF CERC)
vrf forwarding CERC
ipv6 address 2001:db8:12::1/64
!
mpls ldp router-id Loopback0
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 10.1.2.0 0.0.0.255 area 0
!
router eigrp CERC-LAB
!
address-family ipv6 unicast vrf CERC autonomous-system 10
!
topology base
redistribute bgp 3549 metric 1000000 10 255 1 1500
exit-af-topology
eigrp router-id 1.1.1.1
exit-address-family
!
router bgp 3549
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2.2.2.2 remote-as 3549
neighbor 2.2.2.2 update-source Loopback0
!
address-family vpnv6
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community extended
exit-address-family
!
address-family ipv6 vrf CERC
redistribute eigrp 10
exit-address-family
!
Two details deserve attention here. First, the redistribution must happen in both directions: EIGRPv6 into BGP (so the local CE routes become VPNv6 routes) and BGP into EIGRPv6 with a seed metric (so the routes coming from the remote PE are advertised to the local CE). If the second one is missing, the VPNv6 routes arrive at the PE but the CE never learns them. Second, EIGRPv6 requires a 32-bit router-id; since the VRF has no IPv4 interfaces, it must be configured manually with the eigrp router-id command.
PE2
PE2 mirrors PE1, with its own addressing and the iBGP session pointing to the same Route Reflector.
hostname PE2
!
ipv6 unicast-routing
!
vrf definition CERC
rd 3549:1
!
address-family ipv6
route-target export 3549:1
route-target import 3549:1
exit-address-family
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Ethernet0/0
description Link to P
ip address 10.2.3.3 255.255.255.0
mpls ip
!
interface Ethernet0/1
description Link to CE2 (VRF CERC)
vrf forwarding CERC
ipv6 address 2001:db8:23::1/64
!
mpls ldp router-id Loopback0
!
router ospf 1
network 3.3.3.3 0.0.0.0 area 0
network 10.2.3.0 0.0.0.255 area 0
!
router eigrp CERC-LAB
!
address-family ipv6 unicast vrf CERC autonomous-system 10
!
topology base
redistribute bgp 3549 metric 1000000 10 255 1 1500
exit-af-topology
eigrp router-id 3.3.3.3
exit-address-family
!
router bgp 3549
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2.2.2.2 remote-as 3549
neighbor 2.2.2.2 update-source Loopback0
!
address-family vpnv6
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community extended
exit-address-family
!
address-family ipv6 vrf CERC
redistribute eigrp 10
exit-address-family
!
CE1 and CE2
The customer routers run plain EIGRPv6 and have no idea that MPLS exists. Here the classic configuration style is enough. Remember that classic EIGRPv6 starts administratively down, so the no shutdown under the process is mandatory, and since these routers have no IPv4 addresses at all, the router-id must also be set manually.
hostname CE1
!
ipv6 unicast-routing
!
interface Loopback0
ipv6 address 2001:db8:1::1/128
ipv6 eigrp 10
!
interface Ethernet0/1
description Link to PE1
ipv6 address 2001:db8:12::2/64
ipv6 eigrp 10
!
ipv6 router eigrp 10
eigrp router-id 11.11.11.11
no shutdown
!
hostname CE2
!
ipv6 unicast-routing
!
interface Loopback0
ipv6 address 2001:db8:2::2/128
ipv6 eigrp 10
!
interface Ethernet0/1
description Link to PE2
ipv6 address 2001:db8:23::2/64
ipv6 eigrp 10
!
ipv6 router eigrp 10
eigrp router-id 22.22.22.22
no shutdown
!
Once everything is configured, it is possible to verify the EIGRPv6 adjacency on the PE-CE link, the VPNv6 routes on the Route Reflector, the label stack programmed in CEF, and finally the end-to-end connectivity between the two customer sites.
Verifying the EIGRPv6 adjacency on PE1
PE1#show ipv6 eigrp vrf CERC neighbors
EIGRP-IPv6 VR(CERC-LAB) Address-Family Neighbors for AS(10)
VRF(CERC)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 Link-local address: Et0/1 11 00:15:42 10 100 0 3
FE80::A8BB:CCFF:FE00:6510
Note that the neighbor appears with its link-local address: EIGRPv6 builds the adjacency over link-local, not over the global unicast addresses. If the neighbor does not appear at all, the two usual suspects are the missing no shutdown under the EIGRPv6 process on the CE and the missing router-id on routers without IPv4 interfaces.
Verifying the VPNv6 routes on the Route Reflector
On the P router we can confirm that the loopback of CE2 arrived as a VPNv6 route, with the RD 3549:1 in front of the prefix and the route-target 3549:1 attached as extended community.
P#show bgp vpnv6 unicast all 2001:DB8:2::2/128
BGP routing table entry for [3549:1]2001:DB8:2::2/128, version 18
Paths: (1 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
Local, (Received from a RR-client)
::FFFF:3.3.3.3 (metric 21) from 3.3.3.3 (3.3.3.3)
Origin incomplete, metric 128256, localpref 100, valid, internal, best
Extended Community: RT:3549:1
mpls labels in/out nolabel/32
Two things to observe in this output. The next hop is ::FFFF:3.3.3.3, the IPv4-mapped IPv6 address of the PE2 loopback, exactly as described before. And PE2 assigned the VPN label 32 to this prefix, which is the inner label that will identify the VRF CERC on egress.
Checking the CEF entry on PE1
On PE1 we can confirm that the route was imported into the VRF and that CEF programmed the two-label stack.
PE1#show ipv6 cef vrf CERC 2001:DB8:2::2/128
2001:DB8:2::2/128
nexthop 10.1.2.2 Ethernet0/0 label 16 32
- Label 16 (outer, transport): learned via LDP, it takes the packet across the core to the loopback of PE2 (3.3.3.3).
- Label 32 (inner, VPN): assigned via MP-BGP, it tells PE2 that the packet belongs to the VRF CERC.
Verifying connectivity between the two sites
CE1#ping 2001:DB8:2::2 source Loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:2::2, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:1::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/5 ms
Analyzing the label stack with traceroute
A traceroute from CE1 shows how the two-label stack behaves while the packet crosses the core.
CE1#traceroute 2001:DB8:2::2 source Loopback0
Type escape sequence to abort.
Tracing the route to 2001:DB8:2::2
1 2001:DB8:12::1 2 msec 1 msec 1 msec
2 ::FFFF:10.1.2.2 [MPLS: Labels 16/32 Exp 0] 4 msec 4 msec 4 msec
3 2001:DB8:23::1 [MPLS: Label 32 Exp 0] 4 msec 3 msec 4 msec
4 2001:DB8:2::2 3 msec 3 msec 3 msec
- Hop 1: PE1 answers from its VRF interface, the packet is still native IPv6.
- Hop 2: the P router has no IPv6 configuration, but it still answers the traceroute. The TTL expired in the middle of the LSP, so the P router builds the ICMPv6 time-exceeded using the IPv4-mapped address of its interface (::FFFF:10.1.2.2) and forwards it to the end of the LSP, where PE2 routes it back to CE1 through the VPN. Both labels are visible: 16 for transport and 32 for the VPN.
- Hop 3: the P router already removed the transport label (penultimate hop popping), so PE2 received the packet carrying only the VPN label 32.
- Hop 4: PE2 removed the VPN label and delivered the native IPv6 packet to CE2.
In summary, 6VPE delivers per-customer IPv6 VPNs with overlapping address support and full traffic isolation, reusing the IPv4/MPLS core as it is: same LDP, same IGP, and P routers that never need to learn IPv6. For a service provider that already operates VPNv4, adding IPv6 VPN services is mostly a matter of activating the VPNv6 address-family on the PEs and defining the IPv6 address-family inside the customer VRFs.
References