[HN Gopher] Is IPv6 faster than IPv4?
___________________________________________________________________
Is IPv6 faster than IPv4?
Author : lladnar
Score : 69 points
Date : 2022-06-14 18:54 UTC (1 days ago)
(HTM) web link (pansift.com)
(TXT) w3m dump (pansift.com)
| candiddevmike wrote:
| Anyone running v6 only and bridging to v4 on the edge?
| pantalaimon wrote:
| Yes we do this for our sensor networks, but usually the gateway
| also has an IPv6 uplink.
| throw0101a wrote:
| > _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.
| bombcar wrote:
| Any details available on how to do this on a home network?
| nix23 wrote:
| Facebook...eh Meta.
| knorker wrote:
| Facebook, Deutche Telecom (Terastream), and other huge players
| I can't mention because NDA.
| candiddevmike wrote:
| 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 wrote:
| 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.
| mugsie wrote:
| I did by accident, and missed the edge bridge :D more things
| worked than didn't to be honest
| kjellsbells wrote:
| 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.
| ipython wrote:
| 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.
| usrbinbash wrote:
| 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.
| crims0n wrote:
| 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?
| gwbas1c wrote:
| 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.)
| capitol_ wrote:
| 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.
| Tepix wrote:
| It says 36.89% here. Weird.
| capitol_ wrote:
| That was badly worded by me, I was only talking about the
| USA numbers, not the global ones.
| rb12345 wrote:
| The 50.03% is specifically US traffic; for global
| traffic, it's 36.89%.
| lmm wrote:
| The US has a disproportionate chunk of IP addresses due to
| the original allocation. Where I live the lack is definitely
| being felt.
| ClumsyPilot wrote:
| 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
| Majestic121 wrote:
| 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.
| jcranmer wrote:
| Since ~2017, the highwater mark of IPv6 availability is
| growing at about 10 percentage points every 21/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.
| tyingq wrote:
| It's mostly phones though, that talk to IPV4 backends via
| gateways. So there's not much pressure on backend services to
| adopt IPV6.
| throw0101a wrote:
| > _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.
| zamalek wrote:
| 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.
| idatum wrote:
| 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 wrote:
| More like BD vs. DVD - 'living with both for a long time' as
| you say, but also one is a clear successor.
| dijit wrote:
| 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.
| RF_Savage wrote:
| 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.
| bombcar wrote:
| When China mandates _shutting off_ IPv4 internally is when
| we 'll see a flurry of activity, but that's probably still
| years away.
| viraptor wrote:
| 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.
| rr888 wrote:
| 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.
| bombcar wrote:
| 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".
| mugsie wrote:
| 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)
| pmw wrote:
| 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.
| technofiend wrote:
| 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.
| mugsie wrote:
| 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 wrote:
| 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.
| kazen44 wrote:
| 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).
| api wrote:
| 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.
| runjake wrote:
| 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.
| blibble wrote:
| 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 wrote:
| >TL;DR: IPv6 is faster than IPv4 ~39% of the time (locally
| anyway!).
|
| Sooo, slower than ipv4 61% of the time?
| setuids wrote:
| Slower _or equal to_ IPv4
| teleforce wrote:
| 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-...
| virtuallynathan wrote:
| Sadly not much stuff supports SRv6, and I'm not aware of many
| deployments.
| kazen44 wrote:
| 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/
| robjs wrote:
| 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.
| teleforce wrote:
| 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.
| robjs wrote:
| 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.
| teleforce wrote:
| 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.
| fach wrote:
| Can we not step back and instead address the practical
| implementation challenges robjs raised?
| iso1631 wrote:
| 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 wrote:
| 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.
| fach wrote:
| 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.
| teleforce wrote:
| 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?
| iso1631 wrote:
| Or perhaps you could link to a wider range of literature
| rather than try to get people to buy a $100 book
| teleforce wrote:
| 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/
| virtuallynathan wrote:
| 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.
| ev1 wrote:
| 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 wrote:
| or when HE has bad/broken routes...
| virtuallynathan wrote:
| 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.
| divbzero wrote:
| Did you have a sense of whether QoE diverged due to differences
| in the networking equipment or differences in the protocol
| itself?
| virtuallynathan wrote:
| 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 wrote:
| 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.
| neilalexander wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Maybe have a look at http://he.net/ and quick links on
| the right side...
| ArchOversight wrote:
| > (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 wrote:
| > (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 wrote:
| > 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.
| craftkiller wrote:
| 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
| lightweb wrote:
| 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.
| lightweb wrote:
| Think a new IP address for every packet.
| lightweb wrote:
| Think on solving BGP vulnerabilities through micropayments.
| lightweb wrote:
| 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 wrote:
| https://www.youtube.com/watch?v=6j0yESuI96c
| toast0 wrote:
| 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 wrote:
| 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.
| [deleted]
___________________________________________________________________
(page generated 2022-06-15 23:02 UTC)