Moving Networks to IPv6 MPLS (Bye-Bye IPv4 MPLS)
Now that the Internet community is done officially launching IPv6 (World IPv6 Launch) on June 6th, it is about time to seriously think about the co-existence of IPv6 and MPLS (i.e. MPLSv6) without relying on IPv4 for any control plane functionality.
Is it possible now? Well, yes (though the mileage may vary).
Does it matter? Oh, absolutely yes.
MPLSv6 is about MPLS forwarding of IPv6 packets. It has existed since 2005 in form of 6PE [RFC4798] and 6VPE [RFC4659]. But MPLSv6 required IPv6 prefixes to use IPv4 Next-Hop for which the ingress router would build an MPLS path to carry the corresponding IPv6 traffic from ingress to egress of the network. In non-technical terms, it means that we’d still need IPv4 throughout the network for MPLS (and therefore IPv6) to work. Consequently, we couldn’t turn off IPv4 under those conditions and we’d be stuck maintaining two protocol stacks in the network forever. Long term we have to start thinking of ultimately getting MPLSv6 off IPv4 clutches – let MPLSv6 not rely on IPv4 in any manner (e.g. IPv4 next-hop or IPv4 transport).
Thankfully, we at Cisco started thinking about how to handle this issue back in 2008 and got serious about true MPLSv6 in 2010, as more and more operators started moving to dual-stack networks. As we investigated, we learned that the MPLS control plane protocol (Label Distribution Protocol or LDP) needed a facelift as the first step so as to avoid reliance on IPv4 altogether. We quickly realized that IETF’s LDP protocol specification [RFC5036] was written with IPv4 in mind, not so much IPv6 in mind. As our investigation (and software implementation) continued, we discovered more gaps & issues (particularly, in the name of dual-stacking). Frankly speaking, I didn’t think that there would be so many issues with LDP to work with IPv6 when we first led the IETF contribution to modify the protocol specification.
We continue to collaboratively push this draft through IETF standardization process for achieving interoperable implementations so as to pave the way for turning off IPv4 in the network. While it gets time-consuming and exhausting (to address each and every technical issues), we stay committed to strive for its publication as an RFC in 2012. Of course, in addition to LDPv6 over IPv6, implementations will have to also allow for MPLS based services (e.g. VPNs) to start making use of IPv6 next-hops in both control plane and data plane, enabling true MPLSv6.
While we may still have other areas (e.g. RSVPv6, MPLS OAMv6) to lead through standardization, I believe that we are very close to clearing the most fundamental road-block for true MPLSv6, and for the IPv6-only network infrastructure that needs to offer MPLS based services (e.g. VPNs) in future.
If you are a network operator, then you’ve got no reason not to enable IPv6 and get ready for true MPLSv6, without relying on IPv4. The future is here!