Is IPv6 faster than IPv4? | Hacker News Reader

Is IPv6 faster than IPv4?

pansift.com

79 pointslladnar88 comments

In many ways, IPv6 stacks are simpler than their IPv4 counterparts. The fixed packet headers are simpler and faster to parse, ICMPv6 includes both router and neighbour solicitation (as opposed to being separate protocols like ARP in IPv4), routers generally won’t fragment large packets in transit (instead giving way to Path MTU Discovery) and NAT is not so widely needed as it is in IPv4.

That said, the fixed packet headers being slightly longer means there’s actually slightly less room for the payload in an IPv6 packet compared to IPv4 on an otherwise equivalent link MTU.

I’m not entirely sure what to make of the results in the article though and the title really should be leading with asking why in order to be less sensational. The only explanation I can think of right now is that many routers have historically deprioritised ICMP traffic or even dropped it when under heavy load, but given that ICMPv6 is much more core to the functioning of IPv6 in general, it is perhaps not as feasible to do so for ICMPv6.

> NAT is not so widely needed as it is in IPv4.

If every device had a globally unique address, is there really a need for NAT?

Nope! There's even an RFC that enumerates all the purposes for NAT and explains why they are no longer needed in IPv6: https://datatracker.ietf.org/doc/html/rfc4864

Yes, because not every entity is an ASN with their own allocation, nor their ISPs will announce their addresses on a residential service, for instance.

I have to resort to NPTv6 in my setup, as my ISP allocates IPv6 prefixes dynamically, breaking down IPv6 routing when they have some issue and drop/change the prefixes previously allocated to me.

I'm not sure incompetence on the part of the ISP really translates into a need for NAT. It's a useful workaround, to be sure, but what you need here is an ISP that handles IPv6 prefixes properly. There is no reason for the prefix delegated to a customer to change, ever. They should just assign it statically when they create the account.

> but what you need here is an ISP that handles IPv6 prefixes properly

It's hard to get ISPs to do things properly in general; if it's for IPv6, it's even more difficult. I think the intent of IPv6 designers was for hosts to manage to be prefix fluid; you might set up ULAs for local traffic, and use whatever prefixes are advertised for non-local traffic. Of course, that's harder to do than to write an RFC about, so I can understand resorting to prefix translation to get things done in the way desired. Prefix translation has the potential to be stateless which is nice for resource management on the translation element, though.

> Prefix translation has the potential to be stateless which is nice for resource management on the translation element, though.

It really messes with protocols where you need to tell another host how to contact you, though, since you don't know your "real" IP address without asking some other server. This gets worse if there is more than one level of translation involved. You also need hacks like "hairpin NAT" (wastefully passing local traffic through the router) since local hosts trying to connect to the public IP of a local server don't realize that they can reach it directly via the ULA.

> … you might set up ULAs for local traffic, and use whatever prefixes are advertised for non-local traffic.

This is the way.

You might not have exactly one ISP.

Imagine you use an RV as a nomadic home office. You have a small LAN with a private server (file server, HTTP server for testing web sites, etc.), and you want that server to have a static IP.

Since you might be on RV park WiFi at one moment, cell data at another, etc., you can't use a static IP from an ISP.

But you can use the IPv6 private address range, and then you need NAT.

(Technically I guess you could do without NAT if you gave every host on your LAN two addresses: a private address and a publicly-routable one. But that might be more cumbersome.)

> (Technically I guess you could do without NAT if you gave every host on your LAN two addresses: a private address and a publicly-routable one. But that might be more cumbersome.)

Except that the IPv6 standard explicitly allows for two on-link prefixes for SLAAC. So in my home I have a ULA address range that is static, and all my devices get a SLAAC random IP from my ISP.

If my prefix changes, that doesn't change my ULA prefix and all DNS records will continue to function. My ULA is also advertised over BGP using Wireguard, so its automatically routable from VPN when I am on the road but I still want to reach internal resources.

> (Technically I guess you could do without NAT if you gave every host on your LAN two addresses: a private address and a publicly-routable one. But that might be more cumbersome.)

For any IPv6 setup, you already have multiple addresses per host. You start with your mandatory link-local unicast address from the `fe80::/10` range and then you add a global address after getting a prefix from your router. I don't see how adding a third address, particularly a static one, would be cumbersome.

Maybe have a look at http://he.net/ and quick links on the right side...

That sounds like a surveillance nightmare...

It seems that this article is missing the forest for the trees. The biggest improvement will come not from the raw speed but from the entire IPv6 eco-system. For example, the new segment routing for IPv6 or SRv6 should improve the Quality of Service (QoS) for examples bandwidth, delay and jitter by having control at the edge. This is unlike MPLS where the control is done in the core itself and that's why MPLS is called layer 2.5 because it's not truly native IP layer or layer 3. This new approach of networking is considered as IP 2.0 [1].

[1]SRv6 Network Programming: Ushering in a New Era of IP Network:

https://www.routledge.com/SRv6-Network-Programming-Ushering-...

SRv6 is not going to transform the quality of experience/quality of service that you see from Internet applications. Traffic engineering technologies like this (MPLS-based, IP-based, emulated circuit based...) are used inside networks to select paths through them, this has been done for many years, and the segment routing data-plane - whether it be MPLS or IPv6, is a different realisation of how to achieve that path selection through a network. There are networks that have done this traffic engineering using IP encapsulation for many years.

The whole "IP 2.0" presumption that appears to be being made here is that suddenly some external traffic source will be able to select a route through someone else's network -- but this just isn't the commercial reality. Some more performant paths are going to have costs associated with them (even if it's just to build more capacity), so there is going to be a cost of choosing that route through the network. That cost is going to need to be covered somewhere - so you are very unlikely to actually be able to get to choosing a path without some commercial contract. Guess what? We've already had those -- they just tend to use the DSCP bits to indicate what the traffic class, and hence associated requested SLO is - not an explicitly chosen path.

Equally, let's think about how this would even work - if you are going to choose a path through the network to get better QoS, you're going to need to know something about what IDs to use, which implies knowledge of the topology. Inter-domain topology exposure is going to /significantly/ increase the complexity and fragility of inter-domain routing -- there are reasons that we don't run a global link-state protocol :-)

In conclusion - I think this is hype with little technical justification, and is unlikely to have any different impact than other intra-domain traffic engineering that the industry has been running for many years.

Yes sure MPLS works as combustion engines work as long we can remember, but it's not stopping EV as a new contender as the near future vehicle platform whether we like it or not. Now we have hybrid MPLS or SR-MPLS as a stopgap measure similar to what we have now with PHEV, etc. Personally I think the networking industry has already learned their mistakes from the ATM days and hopefully SRv6 will take off for better and more effective IP based networking.

I don't understand what this means. This was not a defence of MPLS, but rather an observation that says that the fundamental domains and business logic around externally-selected TE paths do not change because we change what header instructs the network to steer packets. It's still not going to make sense to have external users try and use the "premium" paths in the network without some recompense to keep scaling them, equally, there needs to be some incentive for users to choose a "less than best" path.

Quite honestly -- this kind of marketing hype and hyperbole is what is wrong with the whole area of SR today (and I say this as someone that was _very_ involved). We've completely lost the ability to say what it is we're solving, and why we're doing it. We're driving disparate architectures into silicon where there's opportunity cost for the functionality. We're having political disagreements within the IETF based on folks trying to keep political control of technologies, not worrying about the efficacy for the industry. It's all pretty broken. YMMV.

Let's us step back and look into the current mess of the existing IP networks with all the duct tapes involved (looking at you NAT). Any QoS that the end users probably want is only make dollar sense for the big companies that's why we have the fine print of best-effort services written in almost all the Telcos' EULA. What IPv6 based technology for example SRv6 is doing is trying to democratize QoS so that it's hopefully affordable to the average Joe. Perhaps it's still a pipe dream at the moment but given the current situations I will take SRv6 over MPLS, or any expensive TE any day. My networking utopia will be a local-first software with cloud vendors and Telcos independence that can utilize the networks based on their required and necessary QoS. I foresee that the best way of going forward is based on this new promising and more affordable technology that the incumbent technology cannot provide.

Can we not step back and instead address the practical implementation challenges robjs raised?

A poor link - a book written by Huwaei doesn't scream "This is a widely used standard"

Wikipedia would be a far better link, as it has links to RFCs, Cisco, Juniper Arista etc pages on it, and generally lets normal people who likely haven't heard of it read about it

Sheesh, it take real guts to dismiss a book written by engineers who themselves directly involved in coming up with open industry networking standards, and currently working with arguably the biggest networking and communication company in the world. This take the idiom of "judge a book by its cover" to a whole new level.

There has been a long history of Huawei stealing IP as well as generating less than useful drafts/standards in the IETF. There are very real reasons to judge this book by its cover.

Sorry to be blunt, but there is a real reason the idiom existed for several hundred years. Perhaps you should read the book so we can have more civilized discussions?

Or perhaps you could link to a wider range of literature rather than try to get people to buy a $100 book

That's fair enough but to simply dismissed a book by the fact that it's written by some qualified and professional company engineers is not acceptable. To be honest there are only two books on segment routing at the moment both are over $100, just trying to be helpful on the book because the recommended one is what I have. Here is the main website for segment routing for the IETF documents, software, papers, etc:

https://www.segment-routing.net/

Sadly not much stuff supports SRv6, and I'm not aware of many deployments.

also, SRv6 in my opinion, is just a mess of security holes [0] and reinventing the same architecture over and over again while it is far more cumbersome to implement in hardware compared to simple MPLS LSP lookups.[1]

[0] https://mailarchive.ietf.org/arch/msg/v6ops/GbWiie-bjQ_Bp1JK... [1] https://packetpushers.net/srx6-snake-oil-or-salvation/

At Netflix, we found in quite a few networks IPv6 had much better QoE than IPv4. In a limited number of cases, IPv6 was very broken. It was almost always equal or better.

Much smaller POV, but when I was dealing with ISP things in past I've found that on many networks v4 might have a nice, redundant blend while frequently v6 is some mix of HE+something or singlehomed HE, which disappoints me. But then the fact that their ports are basically unused other than for the usual G/YT/FB traffic makes the v6 pretty uncontended.

Luckily we have embedded OCAs and/or peering with almost every network of significant size, so their choice of transit rarely comes into the mix.

or when HE has bad/broken routes...

Did you have a sense of whether QoE diverged due to differences in the networking equipment or differences in the protocol itself?

There's an awful lot of very old IPv4 equipment still hanging around, but most of the IPv6 stuff is newer - so if IPv6 is working it's probably a more recent piece of hardware.

I believe in 1 case it was pathological issues with some networking equipment, but this was a recent thing, so I haven’t looked into everything yet.

Does who (ISP and end user) enabled IPv6 tend to have good network equipment / end device?

I still can't get away from this sensation that no matter how good IPv6 is, the ship has sailed. The inferior but indisputably cheaper technology won out over the technically superior one. VHS vs Betamax. Ethernet over Token Ring.

Yet, while people keep saying that, ipv6 adoption only goes up every month. I'm having a hard time accepting "the ship has sailed" while my home outbound connections use ipv6 for more and more endpoints.

Yeah, definitely. I made a mistake a while back, and swapped one of my testing networks to v6 only, and I was surprised I only noticed things were broken after a few days (looking at you github).

I think it has a lot to do with people being put behind cloudflare etc, and getting v6 basically for free

I think businesses are holding up wider V6 deployment. In a lot of them that I've worked with, you don't talk about v6 as it's either a thing no one wants to learn or has no value worth implementing.

meanwhile in the SP world, most core networks can support IPV6 quite trivially because it is either just another payload that is labelled and put into an MPLS environment, or when we need connectivity for our own nodes, it is quite trivial to achieve. (especially if you run BGP or IS-IS as an IGP).

IPV6's address space starts to make a hell of a lot of sense when you look at microsegmentation. And by that I mean you don't need to deploy carrier-grade NAT behind your firewall to mask reuse of one of IPV4 class A networks.

All the cloud provider VPCs seem inextriciably linked to IP4 config, which seems to work great. Maybe the low level infrastructure is IP6, but we dont operate at that level.

I'm starting to think the cloud providers are hoarding IPv4 addresses and see them as an asset, and don't want to "rock the boat".

starting? :) - definitely are. It is also a chicken and an egg problem - until people start shouting they won't implement v6, and people won't want it until there is a reason too (like not getting v4 addresses - which cloud providers solve by just NATing the world)

AWS supports IPv6 on non-default VPCs: https://docs.aws.amazon.com/vpc/latest/userguide/get-started...

I have a hobby project on AWS using it today, with multiple EC2 instances having IPv6 addresses. It works beautifully.

You're talking about displacing an incumbent, not competing technologies.

IPv6 will win, once people stop sitting on their hands. Companies now are being effectively forced to adopt it due to exhaustion of the range.. CGNAT is bigger than ever and is causing real issues so most phones are dual homed with IPv6 behind a v4 CGNAT.

Like climate change, its a "future problem" until its practically staring you in the face, at which point its too late or very painful to solve..

Nihlism isnt helping.

All cheap stuff will support IPv6 due to China mandating full IPv6 support. I suspect China will eventually drag the kicking and screaming west to IPv6-land.

When China mandates shutting off IPv4 internally is when we'll see a flurry of activity, but that's probably still years away.

The original RFC came out in 1995, the modern RFC used today in 1998 - almost 25 years ago. When I was in college in 2012 (going through the Cisco NetAcad) they were preaching that our IPv6 future was "just around the corner". I am going on 10 years in network and security now, and I still don't see it. At least in the US, IPv4 is, and will remain, the dominant force.

There are many reasons for this, but one of the biggest is - from a practical standpoint, the only thing wrong with it is the lack of addresses. Even the perceived shortage is hardly felt though - what is the going rate of an Elastic IP not associated with an EC2 instance these days, $0.005 per hour?

Came to make a similar comment, except that my "IPV6 is just around the corner" in college moment came in 2000.

I personally don't understand the holdup... I've seen so many forced upgrades as a consumer, and even more as a technology developer, that it seems like by now some group should be able to pick a cut-over date. (Examples: the 3G shutdown, TurboTax told me that my computer won't be supported next year, VHS tapes no longer being made, ect.)

As of I'm writing this google sees 50.03% of its traffic on v6. According to https://www.google.com/intl/en/ipv6/statistics.html

Maybe dominant is the wrong word, large might be better.

It says 36.89% here. Weird.

That was badly worded by me, I was only talking about the USA numbers, not the global ones.

The 50.03% is specifically US traffic; for global traffic, it's 36.89%.

The US has a disproportionate chunk of IP addresses due to the original allocation. Where I live the lack is definitely being felt.

To have some data : https://www.google.com/intl/en/ipv6/statistics.html

While progress is slow, it is constant and we're reaching 40% of IPv6 availability in 2022, from pretty much 0% in 2010.

I'm confident we'll get there.

> While progress is slow, it is constant and we're reaching 40% of IPv6 availability in 2022, from pretty much 0% in 2010.

I always find it amusing that IPv6 usage peaks on weekends. Seems home and mobile users have better IPv6 connectivity than corporate users.

I have been using IPv6 for years on my mobile plan, so anecdata supports your hypothesis.

But it's not only corporate. IPv6 only lit up at home (Verizon Fios) for me maybe 1 month ago. There are also likely very few people with RA enabled, even if their infrastructure supports it.

It's mostly phones though, that talk to IPV4 backends via gateways. So there's not much pressure on backend services to adopt IPV6.

Since ~2017, the highwater mark of IPv6 availability is growing at about 10 percentage points every 2½ years. At that rate it will hit 100% in 15 years, although I expect the penetration will tick up a bit in ~5 years.

No, it’s just happening without much fanfare in the background. Most mobile networks are ipv6 first, for example. And since mobile is where most of the new deployments and growth are, that’s why they’re getting ipv6 first.

IPv6 adoption isn't a matter of preference or price, it's an inevitability. We can do tricks like NAT all we want, fact of the matter is: Every day, more and more devices that require a public address, connect to The Internet.

Once the address space is exhausted, the only choices are: IPv6 or no new devices. Since the latter isn't an option, IPv6 is inevitable.

IPv6 is core infrastructure, not a silicon valley startup. Just like renewables, the switching of infrastruvture is londlger than 3x of average startup life expectancy

You’re talking like ipv6 isn’t already here. On my large (~100k clients) dual stack wide area network, 75% of internet traffic is ipv6.

I get that feeling sometimes too. I think though it's not going to be so clear a winner as with your examples. We'll be living with both probably forever.

Maybe an example for comparison is iPhone vs Android, or Windows vs Mac? We'll be living with both for a long time too.

More like BD vs. DVD - 'living with both for a long time' as you say, but also one is a clear successor.

Agree.

IPv6 adoption continues to rise. It just takes absolutely forever to shift the fundamental protocols of something as big as the Internet. The time required for the transition was vastly underestimated.

This test is pretty flawed:

> IPv4 requests went first, then IPv6, and we recorded the average latency of the 3 requests as the resulting data point (using a float value in milliseconds).

On wifi, the IPv4 requests are going to wake up your radio, and then the latency is going to be better for the IPv6.

On wired, there's very little difference, since there's no radio wakeup delay.

Pinging your default gateway isn't much of a test anyway.

This is great feedback thanks and a very interesting point. Most laptops these days are constantly chatting towards the Internet, just have a look at wireshark! But, the local LAN tests are preceded by IPv4 and IPv6 Internet reachability tests (which the article mentions regarding only taking results from hosts that were concurrently online with dualstack lighthouse reachability. This test suite takes about 7 seconds total and records about 25-30 data points). If we re-run the test we could indeed let IPv6 go first or do them in parallel to account for any sleeping radios.

Anyone running v6 only and bridging to v4 on the edge?

> Anyone running v6 only and bridging to v4 on the edge?

If you are on T-Mobile USA you are IPv6-only on your mobile device:

* https://www.youtube.com/watch?v=d6oBCYHzrTA

* https://www.youtube.com/watch?v=nNMNglk_CvE

Lots of folks are probably IPv6-only without realizing it.

Facebook, Deutche Telecom (Terastream), and other huge players I can't mention because NDA.

Any tips on how they're doing DNS64/NAT64? Last I looked, TAYGA was a way to do it with a linux edge router. Do folks use Google's DNS64 resolver?

T-Mobile US does 464XLAT and wrote RFC6877 on it: https://datatracker.ietf.org/doc/html/rfc6877

There's a lot more info on how its done if you search 464XLAT on the web.

I did by accident, and missed the edge bridge :D more things worked than didn't to be honest

Yes we do this for our sensor networks, but usually the gateway also has an IPv6 uplink.

Any details available on how to do this on a home network?

On a large commercial network, there's a distinct 'backbone' and self-controlled 'iot' and 'end users', and of the 3 only end users need v4. Compare that to a home environment where there's pretty much all devices need v4, and there aren't too complicated firewall rules going on, it makes less sense to split into a backbone and v6 only devices. Still, you could do it using something like DNS64 if you really wanted to.

Rent a v6 supported VPN or VPS?

Facebook...eh Meta.

certainly isn't on my underpowered home router, which has offload for ipv4 but none for ipv6

can do ipv4 at gigabit without an issue, ipv6 caps out at around 300mbit

>TL;DR: IPv6 is faster than IPv4 ~39% of the time (locally anyway!).

Sooo, slower than ipv4 61% of the time?

Slower or equal to IPv4

IPV6 becomes supercharged when you layer it with the original Bitcoin protocol. It integrates Cryptographic Generated Addresses in IPV6 which is an extension that has been around for awhile but never implemented.

Here is the founder and chair of the IPV6 forum giving a speech about it just a couple of weeks ago: https://www.youtube.com/watch?v=dE3Vsbo1NPs

Really cool engineering things are being worked on in the background.

Think a new IP address for every packet.

Think on solving BGP vulnerabilities through micropayments.

Originally, Bitcoin had no limits in place including the block size. That was added later.

The original protocol scales to trillions of transactions per second. The secret is the Merkle tree and the block header. The block headers only take up megabytes and are easy to keep track of and distribute.

Simplified Payment Verification was outlined in the whitepaper.

The protocol is meant to be used between peers, not between users and nodes.

https://www.youtube.com/watch?v=6j0yESuI96c

Reply on news.ycombinator.com