Should I use 6PE or native IPv6 transport?

One of my students was watching the Building IPv6 Service Provider Core webinar and wondered whether he should use 6PE or native IPv6 transport:

Could you explain further why it is better to choose 6PE over running IPv6 in the core? I have to implement IPv6 where I work (a small ISP) and need to fully understand why I should choose a certain implementation.

Here’s a short decision tree that should help you make that decision:

The decision tree should help you answer the question: “should I use native IPv6 transport or IPv6-over-MPLS for the global IPv6 connectivity?” L2/L3 VPN services are out of scope.


Do you already have MPLS in your network?

  • Yes: Do you use features like MPLS TE or FRR?
    • Yes: you must use 6PE.
    • No: you could run IPv6 natively. Do you run BGP (for Internet services) on all core routers?
      • No: Don’t change the network design, use 6PE.
      • Yes: You could run either native IPv6 or 6PE. Native IPv6 requires IPv6 deployment on all core routers. 6PE needs IPv6 only on PE routers and route reflectors.
  • No: Are you willing to deploy MPLS?
    • No: Forget 6PE, use native IPv6.
    • Yes: Will you deploy IPv6 gradually (only on a few PE-routers)?
      • Yes: Introduction of MPLS and 6PE might make sense.
      • No: Forget it, doesn't make sense to introduce MPLS just for IPv6

More information

To get an initial overview of what’s needed to deploy IPv6 in your network, watch the Service Provider IPv6 Introduction or Enterprise IPv6 – the first steps webinar. You’ll find network core design and deployment guidelines in the Building IPv6 Service Provider Core webinar; IPv6 access network design and deployment are described in the Building Large IPv6 Access Networks webinar. You get access to all four webinars (and a dozen more) with the yearly subscription.

Need help?

I can review your design or you could engage our professional services team in a full-blown network design/implementation project or customized on-site training/design workshop (some global organizations already did).

13 comments:

  1. IMO the "questionary" is valid only for transit services:
    customer L2/L3 services should be took into account!

    ReplyDelete
  2. Good point. Made your observation very explicit. Thank you!

    ReplyDelete
  3. You should add a question "Do I want to use IPv4 building blocks to carry IPv6 packets and doom myself to not switch off IPv4 in my network forever?"

    Cheers, Jan

    ReplyDelete
  4. One question I have is, why is BGP neccessary on all Core routers to run native IPv6? I would think it is best to not have BGP running on all core routers, only on PE and RR.

    ReplyDelete
  5. I did not understand the reasons for having to run 6PE if you have TE/FRR.

    I found your old post http://blog.ioshints.info/2010/03/is-ismpls-tenative-ipv6fail.html that says that auto route will not work but would "traffic-eng forwarding-adjacency" be an option?

    Also if you do not require TE but need FRR could you use LDP with Loop-Free Alternates or is there also an issue with IPv6 and Loop-Free Alternates?

    ReplyDelete
  6. IPv6 and MPLS don't mix well (yet). There is no LDP for IPv6, so you can't map an IPv6 FEC to MPLS LSP. Also, because MPLS TE relies exclusively on IPv4, it cannot modify the IPv6 forwarding table. Actually, IS-IS tries to do just that and fails miserably.

    You can run IPv4 over MPLS/TE/FRR, and native IPv6 in parallel, which means that IPv6 won't enjoy the protection offered by MPLS FRR. If that's OK, go ahead. If you want very FRR-based convergence for IPv6, use 6PE.

    LFA for IPv6 is definitely possible, but not implemented (AFAIK).

    ReplyDelete
  7. Did you purposely omitted the suboptimal exit point selection problem associated with 6PE and OOB route-reflection? :) For an ISP, this could be a serious problem as IPv6 connectivity grows.

    ReplyDelete
  8. How would 6PE behave worse than native IPv6 connectivity in this particular perspective? It is true that 6PE uses IPv4 topology to forward traffic, but assuming IPv4 and IPv6 topologies are congruent, 6PE-based forwarding should follow the same path as native IPv6 forwarding ... or am I missing something fundamental? Wouldn't be the first time ...

    OOB route reflectors are obviously a different story, and I'm well aware of your opinion on that matter 8-)

    ReplyDelete
  9. well, so the assumption is that 6PE will most likely use centralized (OOB) RRs as it's "common sense" in MPLS environments (oh the joys of BGP-free core). I haven't seen much people re-using in-band reflectors they have for IPv4 for their vpnv4/ipv6 reflection :) Of course, it's fine as long as IPv6 is not densely deployed/used, but one day a solution similar to ORR might be needed. Though hard to tell the inflection point where suboptimal routing for IPv6 might start causing real problems.

    ReplyDelete
  10. OK, now I get it. thank you! BTW, there's a "solution" for this problem: BGP add-paths. Pretty sure it's not implemented for IPv6 :'(

    ReplyDelete
  11. It is best to not run BGP when you don't have to and hence one of the benefits of using IP/MPLS. However, as previously mentioned, there are no label distribution protocols for IPv6. Therefore it's necessary to run either BGP on IPv6 across your whole core or you could redistribute into your IGP (an extremely terrible idea >:o ).

    ReplyDelete
  12. To clarify the first statement, to not run it across your core when you don't have to. Apologies for the inexplicable triple post as well.

    ReplyDelete
  13. I just found "bgp-ipv6: Specifies IPv6 BGP LSPs, that is, BGP4+ LSPs" on H3C´s homepage. I´m wondering what HP/H3C is actually talking about here, then?

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.