1. v4-over-v6 MVPNs

2. 4-over-6 MVPNs Objectives
CE based service
Offered as a IPv6 core service
Automatic detection of member CE routers
No new protocol developments or modifications (ie yet one more BGP mod…)
Precise replication of multicast traffic to only member Ces
No address collision between VPN customers group address assignments
Unicast VPN services could use the same solution.

3. 4-over-6 MVPNs Highlights
CE-managed service.
ISP based PE and P routers just run IPv6 and PIM
No PE and P additional configuration or functionality
ISP infrastructure uses IPv6 PIM so precise multicast replication can be performed among the VPN sites.
Each VPN customer is assigned an IPv6 Multicast scoped prefix
The high-order bits are used to create a Multipoint tunnel used between the VPN customer sites so dynamic discovery of CE devices can occur.
Broadcasting over the tunnel is realized by using IPv6 multicast in the underlying network.
ARP is used to realize the underlying tunnel endpoint.
ARP over the multipoint tunnel for a VPN-based next-hop (on the tunnel's subnet) and the hardware address returned is a CE IPv6 address internal to the core.

4. 4-over-6 VPNs IPv6 PIM runs in the core.
PIM runs with the IGP at each site as well as over the multipoint tunnel.
Sending IGP and PIM Hellos are "broadcasted" over the tunnel.
only the CE routers will get the packets (the underlying network will multicast to the correct places only).
IPv6 multicast encapsulated ‘L2’ interconnecting remote customer networks
CE routers are simply configured with an underlying IPv6 multicast address (and possibly a key so the tunnel can be IPsec) to identify the multipoint tunnel for the VPN.

5. 4-over-6 VPNs Packet Forwarding
Unicast packets are forwarded at the customer site as IPv4 packets to the edge of the network following the IPv4 default route.
CE routers will encapsulate the IPv4 packets in IPv6 and send to the hardware address learned for the multipoint tunnel.
Destination CE router will decapsulate and forward on inside IPv4 header to unicast destination.
Multicast can run in any of ASM, SSM, and Bidir mode. For ASM and Bidir, the RP can be located at any of the VPN sites.
For joining SSM channels, the member in the receiver site will join a (S,G) which are IPv4 addresses.
The IGP routing within the VPN allows the PIM join to travel to the edge and over the multipoint tunnel. VPN internal multicast state is setup via normal IPv4 PIM.

6. 4-over-6 VPNs Packet Forwarding
Forwarding to receiver sites could be a subset of all VPN sites, so you want to have precise replication/forwarding and don't want the IPv4 multicast packets to go over the multipoint tunnel.
Possibly triggered to limit core state explosion
The CE router(s) in the receiver sites will take the IPv4 PIM (S,G) join (? - after sending it over the multipoint tunnel - ?) and build an IPv6 PIM (S,G) join.
S is the underlying IPv6 address of the CE router at the source site and G is a group address derived from the IPv4 (S,G) address.
The IPv6 group address could be ff18:vvvv:ssss:ssss:gggg:gggg::x where s and g are the nibbles of the IPv4 (S,G) address and vvvv is a 16-bit VPN ID value - same 16-bit VPN ID value used for the multipoint ARP tunnel
The 16 bit prefix can be one of several possibilities: ff05, ff08, or could possibly have an new scope ID assignment. The T flag may also be 1.

7. 4-over-6 VPNs Packet Forwarding
The IPv6 (S,G) route in the core allows precise replication for the multicast flow.
IPv6 group address is globally unique because the VPN ID is included in the address.
For debugging purposes in the core, you know the IPv4 (S,G) address since it is embedded in the IPv6 group address.
The same infrastructure can be used for both unicast and multicast VPN services.

8. 4-over-6 VPNs IPv4 Customers Customer A IPv6 Core Customer ACE PE CE
Customer B PE P P
Customer B CE PE CE P
IPv6 multicast address is assigned per VPN customer with the embedded VPN ID vvvv:
ff18:vvvv:: PE CE
Customer A

9. 4-over-6 VPNs ff18:vvvv:: IPv4 Customers Customer A IPv6 CoreCE PE CE
Customer B PE P P
Customer B CE PE CE P
Multipoint tunnel using the VPN ID IPv6 multicast address is used for dynamic discovery of CE devices PE CE
Customer A

10. 4-over-6 VPNs ff18:vvvb:: IPv4 Customers Customer A IPv6 CoreCE PE CE
Customer B PE P P
Customer B CE PE CE P
ARP over the tunnel for a VPN-based next-hop (on the tunnel's subnet) and the hardware address returned is a IPv6 address internal to the core. PE CE
Customer A

11. 4-over-6 VPNs ff18:vvvb:: IPv4 Customers ff18:vvvr:: Customer A
IPv6 Core
Customer A CE PE CE
Customer B PE P P
Customer B CE PE CE P
Each VPN customer is assigned a unique VPN ID IPv6 core-scoped multicast address. PE CE
Customer A

12. 4-over-6 VPNs V4 (S,G) join IPv4 Customers V6 (S,G) join Customer A
IPv6 Core
Customer A CE
Sv4 PE CE
Customer B PE P P
Customer B CE PE CE P
Receiver sends v4 (S,G) join PE
Receiver CE converts v4 (S,G) join to core v6 (S,G) join where:
S = Source CE IPv6 core address
G = ff18::vvvb::Sv4:Gv4:xxxx CE
Customer A

13. 4-over-6 VPNs V4 (S,G) join IPv4 Customers V6 (S,G) join Customer A
IPv6 Core
Customer A CE
Sv4 PE CE
Customer B PE P P
Customer B CE PE CE P
Receiver PE converts v6 (S,G) join back into v4 (S,G) join using the Sv4 and Gv4 learned from the embedded addresses of the V6 join. PE CE
Customer A

14. 4-over-6 VPNs V4 (S,G) join IPv4 Customers V6 (S,G) join Customer A
IPv6 Core
Customer A CE
Sv4 PE CE
Customer B PE P P
Customer B CE PE CE P
Precise multicast state is maintained inside the V6 core. PE
No address collisions between VPN customers. CE
Customer A
Data only travels to interested VPN edge sites.

15. 4-over-6 VPNs V4 (S,G) join IPv4 Customers V6 (S,G) join Customer A
IPv6 Core
Customer A CE
Sv4 PE CE
Customer B PE P P
Customer B CE PE CE P
Because the VPN customer IGP runs over the same VPN ID core-scoped multicast group, and the CE endpoints are all known (automatically) the same infrastructure can support BOTH mcast and ucast VPN services PE CE
Customer A

16. Greg Shepherd shep@cisco.com
Thank You
Greg Shepherd