What IPv6 Transition Mechanisms Are Actually Being Used?

An engineer watching my IPv6 Transition Mechanisms webinar sent me this question:

We would appreciate any insight you might have as to which transitional mechanisms the ISPs are actually deploying.

All of them ;)

  • It started with 6rd used by ISPs who could not upgrade the access network to IPv6.
  • I’ve seen plenty of ISPs using DS-Lite or CG-NAT.

IPv4-to-IPv4 CG-NAT is should be the hack-of-last-resort for people who believe they cannot roll out IPv6 for whatever reason. Please try to do anything else but this. See also Lindsay's comment below.

  • Some use MAP-T or variants with table-based mapping for address/port ranges into IPv6 endpoints (example: Deutsche Telekom). There are open-source products out there translating 20Gbps of MAP-T traffic per x86 core.
  • Some mobile operators are deploying IPv6-only networks and using NAT64 (+464xlat) to get to IPv4-only content.

Have I missed anything? Please write a comment!

More to explore

You’ll find a whole series of IPv6 webinars and other useful resources on ipSpace.net IPv6 resources page. Get all of them with an individual or team subscription.

9 comments:

  1. LISP. ofcoz I do not know if any operator is using it or have mapping system that is publicly available.
    Replies
    1. Looks like you missed the "actually deploying" part of the question ;)
  2. I disagree with this "IPv4-to-IPv4 CG-NAT is the hack-of-last-resort for people who believe they cannot roll out IPv6 for whatever reason"

    Rolling out IPv6 doesn't solve the lack of IPv4 problem if you're a residential ISP - you still have to use some form of NAT to provide access to IPv4 resources for your customers. CG-NAT doesn't require anything on the CPE side, so it works for most situations where you don't control the endpoints or CPEs.

    I'm not convinced that the other mechanisms (like 6rd, DS-Lite, 464xlat) are much better than CG-NAT, nor do they solve the same set of problems

    Of course, you want to have IPv6 alongside CG-NAT, so clients can use native IPv6 where possible. This reduces load on your CG-NAT infrastructure, which helps the business case for making IPv6 available to customers.

    Just to be clear, I am a believer in moving to IPv6 wherever possible. I would never argue in favour of CG-NAT *instead* of IPv6. Instead I think it's a complementary approach, that helps those ISPs that don't have massive legacy IPv4 allocations.
    Replies
    1. And of course you're right. Added a remark. And yes, DS-Lite is the same as CG-NAT. MAP is better.
    2. Thanks. I probably should do some reading on MAP-T too, I'm not so familiar with that one.
    3. Also, don't forget about law enforcement regulations: in several regions, ISPs are mandated to be able to uniquely identify a customer (usually, given a public IP, timestamp and - possibly but unlikely - source port).

      That complicates dual stack rollout as you can't just NAT all your v4 eyeballs together. If you decide to go for NAT44, you need some sort of deterministic CGNAT in order to be compliant. Sadly (and stupidly?), from that standpoint, v6 is not a solution.
  3. What about 6PE and 6VPE, are these solutions being widely deployed out there?
    Replies
    1. they are. but as it was mentioned these technologies don't solve the biggest problem -> "lack of IPv4 addresses"
      it's very easy rolling out 6PE/6VPE in ISP core, I've seen both of these in my previous companies.
      but it's a real challenge rolling out IPv6 for residential customers. I've seen CG-NAT and DS-Lite but also need to read about MAP, not familiar with this one
  4. At some point it will move to "just deploy native IPv6 and outsource IPv4 to a specialised company that offers NAT64/MAP/DS-Lite/etc services over the top".
Add comment
Sidebar