Cisco Logo


Architect & DE Discussions

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.

LDPv6 over IPv6

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!

In an effort to keep conversations fresh, Cisco Blogs closes comments after 90 days. Please visit the Cisco Blogs hub page for the latest content.

11 Comments.


  1. I like that but it’s long over due…C’mon! This should have been out long since

       0 likes

    • I agree and hope that it will get a lot more traction going forward. It is surprising that many find 6PE/6VPE to be enough. :-o

         0 likes

  2. Thanks for the update Rajiv. It is bizarre it has taken this long. Native v6 would likely speed adoption.

       0 likes

    • Brent,

      Yah, as we get serious about deploying IPv6 only networks, we will have to have LDP over IPv6. Curious if you are aware of such deployments (outside Japan). How long do you think that the networks will stay dual-stack based?

         0 likes

  3. Thanks for good information…

       0 likes

  4. As things get tight with IPv4, we’re looking for places were we can ‘stretch’, and one such place is on networks that provide ONLY VPN services, and no internet (IPv4) service.

    This is urgently needed and I hope it gets published soon.

       0 likes

    • Hi Josh, I agree…sooner the better. Of course, one could argue that the MPLS network can be addressed using private IPv4 space while providing VPNv4 or VPNv6 services. Of course, relying on private IPv4 going forward is not the best idea.

         0 likes

      • We have considered this, and are doing it in some places. As we move to more consolidated OSS, we need the ability for a single server farm or IP space to have a path to ALL network equipment.

        While we could address this need many ways (VPNv4 as you mentioned, or other methods), the general consensus is we do not want to layer additional technologies and complexity on top of what is really a rudimentary problem. We want to recover the public v4 space we are having today, and do not have enough private space to remain unique across our enterprise.

        At the end of the day, these autonomous(ish) networks are facing the same problem the internet will be soon on a smaller scale. The address space available (RFC1918) is insufficient. The simplest solution would be IPv6, but… Unfortunately its not ready yet.

        Looking forward to seeing this completely implemented.

           0 likes

        • Josh, you make a really good point. If private space (RFC1918) is not always sufficient (given the network hierarchy or given the number of devices/subnets), then IPv6 is the ONLY sane path forward, especially when all the devices need to be reached from the single server farm. We (vendors) need to do a better job wrt IPv6 and at a faster pace.

          Out of curiosity, how many devices do you have? And how are you tackling this problem (e.g. lack of IPv4 address space) at the moment in your environment?

             0 likes

  5. Hi Rajiv, I missed your comment a few weeks back. I love seeing a product manager like you so engaged and actually listening to user community. Pretty awesome.

    Last winter redesigning our statewide regional network we would absolutely have deployed LDPv6 rather than v4. The main reason would be to future proof the native tables. Seems the lifespan of gear is getting longer so if we can deploy P nodes and never go back and touch them until its time to replace it that would be nice. I guess if v6 never adopts then its all for naught but I think once ARIN exhausts in the states.

    One other thing I am noticing that has nothing to do with waiting on standards bodies is the lack of PE to CE IGPs. Last I looked OSPF and ISIS are still not supported. that is pretty weak for dual stack environments at the edge. I assume it is just lack of demand since that would be software deliverables in features but feature parity between v4 & v6 is obviously important if anyone is expected to take on the operational burden with very little value other than a tax.

    Cya!
    -Brent

       0 likes

    • Hi Brent, good to hear from you. Sorry about the delayed response. IPv6/MPLS (e.g. LDPv6) would be desirable and reasonable in any deployment as long as the applications (e.g. L3VPN) can make use of the resulting LSPv6. LDPv6 support is good step 1 nonetheless, and needless to say that mere software upgrade would get most networks past the step 1.

      As far as OSPFv3 on PE-CE is concerned, it is a standard (RFC6565) that is supported across many vendor devices (e.g. IOS-XR 4.1), though OSPF usage on PE-CE is minimal in typical IP/VPN environment/offerings by SPs. Wrt ISIS on PE-CE, there is a barely any deployment, nor any standard. You are right on when you say “just lack of demand” .

         0 likes

  1. Return to Countries/Regions
  2. Return to Home
  1. All Architect & DE Discussions
  2. All Security
  3. Return to Home