Mythbusting IPv6 with Jan Zorz, and Why IPv6 Adoption is Slow

IPv6 was developed in the late 1990s as a successor to IPv4 in response to widespread concerns about the growth of the Internet and its potential impact on the existing IPv4 address protocol, in particular potential address exhaustion. It was assumed that after some time as a dual-stack solution, we would phase out IPv4 entirely. Almost twenty-five years later, however, we are approaching full-scale depletion of IPv4 addresses, in part because IPv6 adoption is still lagging. Indeed, according to Geoff Huston, the current figure of IPv6 deployment worldwide is at only 30% while just 30% of the Alexa Top 1,000 websites are reachable via IPv6. It remains unclear how long a full transition to IPv6 may take.  

‍

‍

The question around the wider pace of IPv6 adoption has become more urgent for us because the fewer networks that operate with the IPv6 protocol, of course, the fewer opportunities there are for adding nodes to monitor it. It’s a classic chicken/egg conundrum. Hence, our inviting Jan Žorž, VP of 6connect Labs, one of the world’s experts on IPv6 adoption, to speak with us about it.  

Jan and Tony sit down to mythbust IPv6 and talk slow IPv6 adoption

Our VP of Operations, Tony Ferrelli, sat down with Jan for a candid, funny and insightful conversation digging into what’s slowing down global adoption, why global operators need IPv6, the downsides to starting with dual stack, as well as busting some of the common myths that surround IPv6.  

Jan has been working as a consultant in the IT field for the last 12 years, specializing in IPv6. He co-founded the Go6 institute in Slovenia to raise awareness of IPv6. Due to its success, Slovenia now leads the EU as the country most prepared for IPv6. Jan regularly presents his work around the world, raising awareness of IPv6 and encouraging its deployment at a national and global level.  

Tony, meanwhile, before running operations at Catchpoint, first met our co-founders in their DoubleClick days where he was Global Networks Manager - ahead of transitioning to Network Manager at Google for over a decade. Thanks to Google’s passion and commitment to IPv6 adoption, Tony gained a lot of exposure to IPv6 (although he admits to fondly looking back at the days of having memorized all the IPv4 addresses in his network).

Below, we share some of the highlights of their conversation in transcript form and to make sure you can partake in some of the more anecdotal, yet still insightful as-hell banter, we’ve included a few video snippets for you to enjoy.

The Q&A: Transcript

‍

The slow pace of IPv6 adoption  

Tony: So, the first question's really loaded. IPv6 came out officially in '98, although a lot was happening before that. Why are we in 2022 now going into 2023, and it still feels like adoption is really slow?

Jan: Well, people invented Network Address Translation (NAT), and this gave them a false sense of security - sort of like, “We can extend the miserable life of the legacy protocol endlessly.” This is the sort of thing that network operators, enterprises and everybody else are still thinking about, even if it’s not what’s really happening... OK, some of them are busy deploying IPv6, but some are still holding on to their old knowledge of IPv4. Why? I'm coming out of the operational environment folks, and I know many, many people that say, “Okay, I know everything about IPv4. I know how to fix IPv4. I know how to troubleshoot IPv4. I know how to deal with it. So why would I implement a new protocol that I don't need?”

Basically, the problem is that sometimes technology people are so focused on their own users, they don’t look beyond that to the wider world. If they can create a private NAT using IPv4 addresses, their problems are solved… for now. Often, in my experience, they don't even know that Google, Facebook and all these big content providers are removing IPv4 from their data centers and moving them onto the edge to the translators.

Recently, Croatia held their first-ever, and they invited me to talk to the Network Operators group about IPv6 and I was like, dude, that's an old story. What the heck, right? And they said, no, come on, talk to our operators. They feel like they don't need IPv6 because they have enough IPv4 space. So, I created a presentation very much at a high level that says, look, this is what content providers around the world are doing. They are putting IPv6 inside their networks. Compare this to what’s happening to IPv4: look, this is still a little translator on the edge. If you, as an ISP, put all your traffic in IPv4 through the translation through the carrier-grade NAT, you are basically connecting over IPv4 to that little translation machine that is on the edge of the network to go and reach the content. That's not very smart.

Tony: Right. You're funneling everything through a single source… so even if it’s a decent-sized device, it causes problems.

Jan: At least double translation.

Tony: Exactly.

Jan: On the next slide, I asked, what if you deploy IPv6? Look at what happens. There is a green path straight from your customers to the content without all the translation shit in between that costs you money. And they were like, “Holy crap, seriously?” I said, “Yeah, that's what's happening. And they were like, “Oh, we didn't know that. We thought IPv6 was sort of something experimental that wasn’t really happening at scale, but hey, now we need to start thinking seriously about this.” I said, “Well, it's about time.”

Tony: You don't think there's any pressure now since ARIN’s running out of space, as is RIPE, which is making it hard to get public IPv4 space... I know places like Google were out of RFC 1918 space years ago. So, what do you think the rationale is? What's holding people back?

Jan: Well, as I said, the big operators and big content providers are finally coming around and there's lots of stuff going on behind the curtains. I have helped many operators around the world to implement IPv6, and it's a process. If you have a small and not very complex network, you can deploy it in a couple of months. Probably. If you have a huge telecom-complicated network, then you probably need a year or two… and that’s if you are very fast.

Going dual stack…

Tony: Do you usually recommend going dual stack to start with?

Jan: It depends. If it's a fixed network, then yeah, it also depends a little bit on the country because you have different legislation surrounding the legal interception necessary.

Tony: Yay governments, getting involved in technical issues.

Jan: Yeah, people find that if you don't adhere to certain legislation, you can lose your operator's license. If I tell them to implement IPv6 and then they lose their license because they were not able to provide the necessary legal interception interface, they would probably start chasing me with sticks and fire!

On the other hand, for mobile networks, there is no reason to deploy dual-stack because 464XLAT works perfectly fine.

‍

Tony: What are some of the downsides to starting off with dual stack?

Jan: It doesn't actually fix your primary problem because you would still have the same problem with not having enough IPv4 space, right?

Tony: Yep.

Jan: It’s just making your problem a bit more bearable. You still have the addressing problem, but at least, if you're a mobile or fixed operator, for example, probably 50% of your traffic would immediately switch to IPv6 as soon as you deploy it - because of Google, Facebook, Yahoo, Microsoft, Apple, etc., operating on IPv6.

Tony: Yep.

Jan: That solves the issue around the carrier-grade NAT (CGN) getting bigger and bigger because if you have just a CGN, you will need to make your network bigger in order to make your CGN bigger, and that involves a lot of money. It's not financially feasible. So, if you deploy IPv6 in dual-stack, you will still have to deal with that CGN, but at least you have an exit strategy because most probably, as more and more content providers deploy IPv6, less and less traffic will go through your CGN box. At some point in time, you can just make it very small or maybe it'll even go away in around twenty years since more and more traffic will go over IPv6. So that fixes your sustainability and money problem. However, it doesn't fix your addressing problem.

Mythbusting IPv6

Tony: Are there any myths and false perceptions that you hear out there about IPv6 that you want to bust right now?

Jan: Well, people say that the divide between the network and the host part should have been better thought of because we lose 64 bits in an instance, right? We lose half of the address space just to number the interface. That could have been thought of a little bit more thoroughly, but hey, IPv6 was created nearly twenty-five/thirty years ago. Still, we have 64 bits. That's better than 32 bits.

Also, people think this means that IPv6 is either less or more secure than IPv4. But it’s the same basically. Other people say that security is built into IPv6 by default. Not really. Okay. You have the option of IPSEC in transport mode, but I don't know many people that have enough knowledge to enable it.

Tony: Right. Can you think of anybody that's enabled it at this point?

Jan: I did the IPSEC in transport mode for the test in the lab.

Tony: But beyond the lab, in the real world?

Jan: I don't think so.

Tony: And why do you think that is?

Jan: Because we are lacking the easy tools to enable it, but especially the tools to distribute the keys. That’s the real problem. If I want to enable the IPSEC in transport mode with you, I need to create a key and send it to you. You need to put it in, and then you need to create a key, need to send it to me, and I need to put it in, and then we start encrypting to each other by default. That's a lot of work.

Tony: Yeah. Until a commercial entity decides they will make this easy, it's likely not going to be adopted… or it's going to take one of the big tech companies to invest the time and resources to figure out the implementation.

Jan: Exactly. It should be like, yes, I want to start encrypting with this guy, this peer, this peer and this peer, and the rest should be automatic.

Multi-homing with IPv6

Tony: Talk to me about multihoming. In v4, it was pretty easy, right? You get your /24, I can go to Verizon and AT&T, I can have two connections, advertise the /24 out, and it's easy. Honestly, if you're not multi-homing today and you run a service, you're a little silly, right? That's a dangerous thing to do. So…

Jan: It’s completely the same as on IPv4.

Tony: Completely the same?

Jan: You need an AS and BGP.

Tony: Yep. And what’s the minimal advertisable netblock that you can do?

Jan: /48

Tony: /48? Do you ever think that's going to go down to a /64? Wouldn’t a /64 be more practical?

Jan: Hell no. There’s a perception that /48 is the size for a site, whatever your definition of a site is.

Tony: What about small startups where you might only have three servers, for instance, at that site?

Jan: You know what I usually tell people? Don’t count addresses, don’t do bean counting. IPv6 is completely different. In IPv6, the network size that is after the address is telling you what the purpose is: /64 for the network, /48 for the site, or for a single home user if you’re generous. If you’re not, you assign /56, right? But don’t go lower than that.

Tony: So, what’s your advice to a network engineer running a service for a company that is globally distributed? Is your recommendation to get a /48 for each of your sites?

Jan: It depends on what is in place in that area. If you’re in a RIPE region, for instance, you will get a /29 as an LIR. Initially, it was /32.

Tony: A lot of us used to go to the ISP and ask them to assign a block. Then they’d assign a /64. But if I want to multi-home that block and I tell them I’m going to run BGP and multi-home, I can only have that /64 with them.

Jan: I started a RIPE 690 document talking about exactly this [see the link below]. We discuss the best current operational practice for operators, including the IPv6 prefix assignment for end users, persistent vs. non-persistent, and what size to choose. When I give tutorials, I usually ask people, how many devices can you put in one /64?

Tony: Why don’t you tell us?

Jan: All of them. And that’s just the addressing for one layer three interface in your house.

‍

Getting IPv6 adoption moving

Tony: So, let’s close this out. Is there anything you want to say to network operators, business leaders, or even government entities, that will help to get IPv6 adoption moving?

Jan: IPv6 is now mature. It’s so old. If IPv6 was human, it would be drinking alcohol.

Tony: So will there be an IPv8 and then IPv16?

Jan: No, no. Looking at the world’s experience with IPv6 over 25 years and its deployment, even if IPV10 or IPV100 is created, I don't think in our lifetime we will ever be able to deploy anything else. So basically, we are stuck with it. People should start thinking about it and get going!

Tony: Do you think governments need to get involved to help the push?

Jan: Well, that's a question. Some people say to leave it to the market. Others say, no, governments should come in and demand it. When I worked for The Internet Society for seven years, I traveled the world talking about IPv6, DNS-SEC, RPKI and all that stuff. And you have different countries and different legislations to work within. So, there is no silver bullet. It's each part of the world by each part of the world.

Tony: Awesome. All right, cool. Thank you very much. Hey, it was a pleasure. It was fun talking with you. I appreciate it.

Jan: It was fun talking with you too. If you have more questions, we can do part two!

Catchpoint's IPv6 Coverage

At Catchpoint, we are continually seeking ways to grow our observability network - to provide as deep and broad monitoring coverage as possible. Often, our customers are the driving force behind where we station our next set of vantage points. Over the last year, one of our largest customers with a daily global user base of over 3 billion, has demonstrated a fierce appetite for adding IPv6 nodes to our network – because IPv6 networks are essential to their infrastructure.  

We are working to do so as quickly as we can – we currently have 264 IPv6 nodes and are adding new ones approximately every two weeks to meet demand.

Learn more

Dig into Jan’s RIPE 690 document regarding prefix size: “Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose”: https://www.ripe.net/publications/docs/ripe-690

Read Equinix’ interview with Tony on the way in which Catchpoint tests environments for our customers based on physical infrastructure distributed globally, providing the ability to test applications where users actually are: https://deploy.equinix.com/customers/catchpoint/

Check out Catchpoint’s full list of global nodes, including our growing IPv6 presence worldwide: https://www.catchpoint.com/global-observability-network