10 ms·

Is IPv6 faster than IPv4?

79 points by lladnar 4y ago

neilalexander 4y ago
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.
- Genbox 4y ago
  > 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?
  - rescbr 4y ago
    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.
    - nybble41 4y ago
      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.
      - adrianmonk 4y ago
        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.)
        LargoLasskhyfv 4y ago
        Maybe have a look at http://he.net/ http://he.net/ and quick links on the right side...
        ArchOversight 4y ago
        > (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.
        craftkiller 4y ago
        > (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.
      - toast0 4y ago
  - craftkiller 4y ago
    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 https://datatracker.ietf.org/doc/html/rfc4864
deleted 4y ago
[deleted]
teleforce 4y ago
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-in-a-New-Era-of-IP-Networks/Li-Hu-Li/p/book/9781032016245 https://www.routledge.com/SRv6-Network-Programming-Ushering-...
- virtuallynathan 4y ago
  Sadly not much stuff supports SRv6, and I'm not aware of many deployments.
  - kazen44 4y ago
    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_Bp1JKB1PlDh_fPdc/ https://mailarchive.ietf.org/arch/msg/v6ops/GbWiie-bjQ_Bp1JK... [1] https://packetpushers.net/srx6-snake-oil-or-salvation/ https://packetpushers.net/srx6-snake-oil-or-salvation/
- iso1631 4y ago
  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
  - teleforce 4y ago
    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.
kjellsbells 4y ago
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.
- idatum 4y ago
  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.
  - OJFord 4y ago
    More like BD vs. DVD - 'living with both for a long time' as you say, but also one is a clear successor.
    - idatum 4y ago
      Agree.
- viraptor 4y ago
  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.
  - mugsie 4y ago
    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
  - candiddevmike 4y ago
    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.
virtuallynathan 4y ago
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.
- divbzero 4y ago
  Did you have a sense of whether QoE diverged due to differences in the networking equipment or differences in the protocol itself?
  - virtuallynathan 4y ago
    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.
  - bombcar 4y ago
    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.
- ev1 4y ago
  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.
  - liveoneggs 4y ago
    or when HE has bad/broken routes...
  - virtuallynathan 4y ago
    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.
candiddevmike 4y ago
Anyone running v6 only and bridging to v4 on the edge?
- nix23 4y ago
  Facebook...eh Meta.
- knorker 4y ago
  Facebook, Deutche Telecom (Terastream), and other huge players I can't mention because NDA.
  - candiddevmike 4y ago
    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?
    - joecool1029 4y ago
      T-Mobile US does 464XLAT and wrote RFC6877 on it: https://datatracker.ietf.org/doc/html/rfc6877 https://datatracker.ietf.org/doc/html/rfc6877 There's a lot more info on how its done if you search 464XLAT on the web.
- pantalaimon 4y ago
  Yes we do this for our sensor networks, but usually the gateway also has an IPv6 uplink.
- throw0101a 4y ago
  > 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=d6oBCYHzrTA * https://www.youtube.com/watch?v=nNMNglk_CvE https://www.youtube.com/watch?v=nNMNglk_CvE Lots of folks are probably IPv6-only without realizing it.
- bombcar 4y ago
blibble 4y ago
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
alex_duf 4y ago
>TL;DR: IPv6 is faster than IPv4 ~39% of the time (locally anyway!). Sooo, slower than ipv4 61% of the time?
- setuids 4y ago
  Slower or equal to IPv4
lightweb 4y ago
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 https://www.youtube.com/watch?v=dE3Vsbo1NPs Really cool engineering things are being worked on in the background.
- lightweb 4y ago
  Think a new IP address for every packet.
  - lightweb 4y ago
    Think on solving BGP vulnerabilities through micropayments.
    - lightweb 4y ago
      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.
      - lightweb 4y ago
        https://www.youtube.com/watch?v=6j0yESuI96c https://www.youtube.com/watch?v=6j0yESuI96c
toast0 4y ago
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.
- irldexter 4y ago
  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.

79 points by lladnar 4y ago

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.

Genbox 4y ago
> 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?
- rescbr 4y ago
  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.
  - nybble41 4y ago
    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.
    - adrianmonk 4y ago
      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.)
      - LargoLasskhyfv 4y ago
        Maybe have a look at http://he.net/ http://he.net/ and quick links on the right side...
      - ArchOversight 4y ago
        > (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.
      - craftkiller 4y ago
        > (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.
    - toast0 4y ago
- craftkiller 4y ago
  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 https://datatracker.ietf.org/doc/html/rfc4864

deleted 4y ago

[deleted]

teleforce 4y ago

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-in-a-New-Era-of-IP-Networks/Li-Hu-Li/p/book/9781032016245 https://www.routledge.com/SRv6-Network-Programming-Ushering-...

virtuallynathan 4y ago
Sadly not much stuff supports SRv6, and I'm not aware of many deployments.
- kazen44 4y ago
  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_Bp1JKB1PlDh_fPdc/ https://mailarchive.ietf.org/arch/msg/v6ops/GbWiie-bjQ_Bp1JK... [1] https://packetpushers.net/srx6-snake-oil-or-salvation/ https://packetpushers.net/srx6-snake-oil-or-salvation/
iso1631 4y ago
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
- teleforce 4y ago
  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.

kjellsbells 4y ago

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.

idatum 4y ago
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.
- OJFord 4y ago
  More like BD vs. DVD - 'living with both for a long time' as you say, but also one is a clear successor.
  - idatum 4y ago
    Agree.
viraptor 4y ago
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.
- mugsie 4y ago
  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
- candiddevmike 4y ago
  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.

virtuallynathan 4y ago

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.

divbzero 4y ago
Did you have a sense of whether QoE diverged due to differences in the networking equipment or differences in the protocol itself?
- virtuallynathan 4y ago
  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.
- bombcar 4y ago
  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.
ev1 4y ago
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.
- liveoneggs 4y ago
  or when HE has bad/broken routes...
- virtuallynathan 4y ago
  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.

candiddevmike 4y ago

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

nix23 4y ago
Facebook...eh Meta.
knorker 4y ago
Facebook, Deutche Telecom (Terastream), and other huge players I can't mention because NDA.
- candiddevmike 4y ago
  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?
  - joecool1029 4y ago
    T-Mobile US does 464XLAT and wrote RFC6877 on it: https://datatracker.ietf.org/doc/html/rfc6877 https://datatracker.ietf.org/doc/html/rfc6877 There's a lot more info on how its done if you search 464XLAT on the web.
pantalaimon 4y ago
Yes we do this for our sensor networks, but usually the gateway also has an IPv6 uplink.
throw0101a 4y ago
> 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=d6oBCYHzrTA * https://www.youtube.com/watch?v=nNMNglk_CvE https://www.youtube.com/watch?v=nNMNglk_CvE Lots of folks are probably IPv6-only without realizing it.
bombcar 4y ago

blibble 4y ago

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

alex_duf 4y ago

>TL;DR: IPv6 is faster than IPv4 ~39% of the time (locally anyway!). Sooo, slower than ipv4 61% of the time?

setuids 4y ago
Slower or equal to IPv4

lightweb 4y ago

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 https://www.youtube.com/watch?v=dE3Vsbo1NPs Really cool engineering things are being worked on in the background.

lightweb 4y ago
Think a new IP address for every packet.
- lightweb 4y ago
  Think on solving BGP vulnerabilities through micropayments.
  - lightweb 4y ago
    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.
    - lightweb 4y ago
      https://www.youtube.com/watch?v=6j0yESuI96c https://www.youtube.com/watch?v=6j0yESuI96c

toast0 4y ago

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.

irldexter 4y ago
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.