Why IPv6 is so complicated

https://github.com/becarpenter/misc/blob/main/why6why.md

by signa11 • 3 months ago

130 494 3 months ago

github.com

leonidasrup• 3 months ago

"The IPv6 mess" by DJB

https://cr.yp.to/djbdns/ipv6mess.html

stingraycharles2• 3 months ago

How I wish that djb time stamped his articles, as I feel like this article is over a decade old but I can’t tell with certainty.

IvyMike• 3 months ago

https://web.archive.org/web/20021203075817/https://cr.yp.to/...

nottorp4• 3 months ago

It's not like anything has changed, except the running out of IPv4 part.

Edit: or maybe they added 12 more extra configuration protocols to manage, in the name of "ease of use".

peyton• 3 months ago

What I don’t understand is why coexistence was so important. TFA notes a lot of protocols were in use back then.

Also what’s with all the problems? I’ve had RA packets leak across VLANs via firewall misconfigurations, some my fault and some not. I get that people designing internet protocols had a lot to think about, but why am I fighting stuff like this?

Etheryte• 3 months ago

The whole world can't migrate all of their hardware on a whim. There was a period of time when it was a very common quip to say that Amazon would have to buy every new IPv6 compatible router in the world for a year if they wanted to upgrade their infra. I don't know if the urban legend is true or not, but the fact that it sounded plausible is a good enough of an example.

Hikikomori4• 3 months ago

And packet forwarding was done in hardware pipelines, can't software update them to handle new protocols.

eqvinox14• 3 months ago

What I don’t understand is why coexistence was so important.

Military, corporate, tech... it isn't. (If your people like flag day migrations. It's… "a choice".) But if you have to explain to an end user why some things work and some don't, you're just f'd.

And note "coexistence" here means that an end host can implement IPv4 and IPv6 at the same time, without them interacting at all. Imagine if you had to choose between IPv4 and IPv6 on your devices, maybe something like "you need a 2nd network card". Can you imagine anyone switching to the less popular protocol?

wongarsu3• 3 months ago

The article describes coexistence as both dual-stack and connectivity between single-stack IPv6 and single-stack IPv4 host. And that in the autor's opinion all the complexity is in the latter, not in the dual-stack

You raise a good point that we also should't take dual- stack for granted. But I think the more precise question 'why not dual-stack as the only coexistence option' also seems like a good one, and one the article does not explore or even acknowledge

rswail• 3 months ago

Because the internet was still a "network of networks".

There were interconnections between DECNET and Novell et al networks and IP networks etc, let alone the push from telcos etc of the OSI models.

IP hadn't "won" the networking space.

themafia5• 3 months ago

The main reason for IPv6, and its only real reason for existence, was bigger addresses.

Which also allowed for better route aggregation in the core BGP tables.

Better node mobility support. Better multicast support. Genuine link local addresses.

IPv4 had a lot of unfortunate edge cases. I think IPv6's greatest strength and also responsible for it's slow rollout was it's insistence on solving several of these problems at once, along with IPSec as the article notes, and hammering them into the hard requirements for the core stack.

foxrider• 3 months ago

And that's what you should do, since you're forcing the protocol update you should take the opportunity that might not come later

apple4ever3• 3 months ago

In hindsight though, and really also in foresight, it didn't work out that way.

ggm2• 3 months ago

Didn't happen. The swamp aside, Traffic engineering drives most disaggregation. Better in some senses, but not orders of magnitude better I think.

ggm2• 3 months ago

India on around 80% in the apnic labs active measurement of end users.

https://stats.labs.apnic.net/ipv6/in

They report nearly a billion users, predominantly in mobile.

So, "only" 750 to 800 million users. Think about that: 3x the population of the USA using it most of the time, in one economy.

Here's the rankings:

https://stats.labs.apnic.net/ipv6/XA?o=cINw30x1r1

This is a different measure to Google's. They measure different things,

nslsm3• 3 months ago

Now compare average income to see how much this matters.

ZeWaka• 3 months ago

very transparent.

harvey9• 3 months ago

Depends what you are selling and to whom. Meanwhile, India wanted to get a lot of people online and this appears to suit their needs.

signa11• 3 months ago

what has _that_ got to do with ipv6 adoption/usage ?

afaics, it probably has more to do with large indian-isp’s f.e. jio adopting ipv6.

kmacdough• 3 months ago

I'm confused. What's your point?

Obviously economies that rely largely on second hand technology are going to have old technology. Much of Africa is in this bucket. But looking past the extremes, India is at nearly 80% right alongside Germany. They fall in very different average income brackets. So the correlation isn't tight.

I can't see any value in pointing out vague correlation between income and proliferation of a new technology. It's the most obvious of observations.

imtringued• 3 months ago

This has nothing to do with income.

The problem here is that India alone would be consuming 20% of the IPv4 address space.

porridgeraisin• 3 months ago

It happened in india mainly due to regulatory pressure[1]. It also helped that around the same time, Reliance (an oil company) launched at a hitherto-unseen pace an entirely new telco (Jio) with only 4G support (now 5G too, but at the time) and zero legacy infrastructure. Airtel (an older telco) was still using ipv4 in lots of cases. However due to pricing pressure[2] and TRAI pressure, they also switched when their 5G rollout happened in 2022. They changed vendors and with that changed the infrastructure as well. So today they are also in good shape ipv6-wise. See also [3]

[1] https://www.dot.gov.in/ipv6-transition-across-stakeholders Edit: hey look the govt drupal page is broken again, shocker. here is another source: https://icrier.org/pdf/IPv6_Transition.pdf

[2] The pricing pressure was _real_. 4G was the first time networks moved away from circuit switched to IP-based. So the marginal cost equation became better. And no legacy infra to support. By 2020, they also had funding from google and meta.

[3] https://broadbandindiaforum.in/wp-content/uploads/2022/08/Re...

miyuru3• 3 months ago

if you want population measurements, there is a APNIC page for that too.

https://stats.labs.apnic.net/v6pop

Fair warning, this page is not optimized and takes a lot of resources to render.

muppetman• 3 months ago

This annoys me, especially the last “It takes at least 25 years” rhetoric.

It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other.

The whole SLAAC/DHCPv6/RA thing is a total clusterfuck. I’m sure there’s many reasons that’s the case but my god. What does your ISP support? Good luck.

We need IPv6 we really do. But it seems to this day the designers of it took everything good/easy/simple and workable about v4 and threw it out. And then are wondering why v6 uptake is so slow.

If they’d designed something that was easy to understand, not too hard to implement quickly and easily, and solved a tangible problem it’d have taken off like a rocket ship. Instead they expected humans to parse hex, which no one does, and massive long numbers that aren’t easily memorable. Sure they threw that one clever :: hack in there but it hardly opened it up to easy accessibility.

Of course hindsight is easy to moan but the “It’s great what’s the problem?” tone of this article annoys me.

SkiFire132• 3 months ago

Instead they expected humans to parse hex, which no one does

Of all aspects of IPv6 you took the only one that doesn't complicate implementations and can easily be swapped if you wanted.

rusk2• 3 months ago

Wait til you’ve got to copy & paste em, or see em comingled with hw addresses

lamonade• 3 months ago

how do you encode 128 bits without making a long number? and not using hex?

b1125• 3 months ago

Far easier to use ipv8, which just has 5 octets instead of 4.

zem2• 3 months ago

have that be the invisible bottom layer. come up with a list of 256 common words, one per byte, and have that be the human visible IP address. mentally reading a string of words, however nonsensical, is way easier than a soup of undifferentiated hex digits.

9dev18• 3 months ago

The whole SLAAC/DHCPv6/RA thing is a total clusterfuck.

SLAAC is easily the thing I love most about IPv6. It just works. Routers publish advertisements, clients configure themselves. No DHCP server, no address collisions, no worry. What's bugging you about it?

muvlon• 3 months ago

What problem is this actually solving? I've deployed DHCP countless times in all sorts of environments and its "statefulness" was never an issue. Heck, even with SLAAC there's now DAD making it mildly stateful.

Don't get me wrong, SLAAC also works fine, but is it solving anything important enough to justify sacrificing 64 entire address bits for?

yjftsjthsd-h3• 3 months ago

I like the ability to

  ping somehostname

on the local network and have it work (where ping can be any command or browser). That's easy with DHCP+DNS, and either impossible or amazingly ugly with DLAAC.

JumpCrisscross2• 3 months ago

What does your ISP support?

My ISP is Spectrum. They get a 0/10 on IPv6 support on this test page [1].

[1] https://test-ipv6.com

collabs• 3 months ago

Is it possible that you own your own router and have at some point configured the router to turn up 6 off? I know it is turned off on my router because I had some issues with Verizon ipv6 and tp link in the past.

mindcrime• 3 months ago

FWIW, I'm also on Spectrum (by virtue of the Time Warner acquisition back in the day) and I get 10/10 on that page. That is, after turning off Firefox "Enhanced Privacy Protection" which actually blocked the page from loading at all for some reason. Got 9/10 using Chrome. Both on Linux.

eqvinox14• 3 months ago

It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP. GPRS/HSDPA/3G/4G/5G They all rolled out just fine and were pretty backwards and forwards compatible with each other.

You're comparing incremental rollout with migratory rollout for most of these; (not the mobile phone standards.) That's apples and oranges.

You can argue for other proposals. But at the end of the day the best you could've done is steal bits from TCP and UDP port numbers, which is... NAT. Other than that if you want to make a serious claim you need to do the work (or find and understand other people's work. It's not that people haven't tried before. They just failed.)

And, ultimately, this is quite close to typical political problems. Unpopular choices have to be made, for the benefit of all, but people don't like them especially in the short term so they don't get voted for.

If they’d designed something that was easy to understand, […]

I can't argue on this since it's been far too long since I had to begin understanding IPv4 or IPv6… bane of experience, I guess.

[…] not too hard to implement quickly and easily, […]

As someone actually writing code for routers, IPv6 is easier in quite a few regards, especially link-local addresses make life so much easier. (Yet they're also a frequent point of hate. I absolutely cannot agree with that based on personal experience, like, it's not even within my window of possible opinions.)

[…] expected humans to parse hex […]

You're assuming hex is worse than decimal with binary ranges. Why? Of course it's clear to you that the numbers go to 256 because you're a tech person. But if you know that, you very likely also know hex. (And I'll claim the disjunct sets between these are the same size magnitude.)

Anyway I think I've bulletpointed enough, there's arguments to be made, and they have been made 25 years ago, and 20 years ago, and 15 years ago, and 10 years ago and 5 years ago.

Please, just stop. The herd is moving. If anything had enough sway, it would've had enough sway 15 years ago. Learn some IPv6. There's cool things in there. For example, did you know you can "ping ff02::1%eth0"?

drob518• 3 months ago

I was at some of those IETF meetings in the mid-1990s and attended some early IPv6 working group sessions. We knew the conversion would take time, but I don’t think any of us thought it would be this slow. I was involved with multiple L3 switches and routers from 1997 through 2010. The issue was always that IPv6 basically required lots of boxes in the middle to understand it in order to roll it out, so when would it be commercially necessary? Yes, you can do tunneling and NAT at various points, but it always requires more than just the endpoints. It shows up in DNS and socket APIs. There’s no easy way to determine if a path supports it, and the path can change in an instant due to a route change. All that is very different than SSL or QUIC where only the endpoints have to be involved. That’s why QUIC uses UDP, for instance, so old intermediate devices just see it as a protocol they already know. SSL just assigned port 443 and the “https” protocol in the web URL. If a web client contacts a server on port 443 that doesn’t use SSL, it just fails. To put it another way, the level of the stack that you’re changing matters. SSL and QUIC are really L5+. IPv6 is squarely L3. There are no protocol negotiation mechanism available at L3. So, from a business standpoint, when do you take the hit and integrate it all into the processing pipeline? How do you do that in a way that doesn’t impact your IPv4 forwarding performance, because that’s what the near-term market will judge you on? How do you afford the development and test cost associated with a whole other development (almost double)? If you’re doing software forwarding, the answers are a lot easier. As soon as you’re designing silicon, it’s a lot harder. When you’re under a lot of commercial pressure, it’s difficult to be the one who goes first. And remember that this hardware evolves on roughly 10 year cycles (2 years for design, 3-5 year market sales, 3-5 year depreciation at the customer before they buy new ones). Oh, and customer rollout of IPv6 is a major project with lots of program management and testing, not just buying a box or two. So, yea hindsight is easy. Eventually you get there, but it’s a long road.

gucci-on-fleek7• 3 months ago

It didn’t take 25 years for SSL. SSH. Gzip encoding on HTTP pages. QUIC. Web to replace NNTP.

All that's required to implement each of those is two computers: 1 client and 1 server. Whereas supporting IPv6 requires every router between the two computers to also support IPv6. Similarly, if your current software doesn't support SSL/SSH/Gzip/etc., it's pretty easy to switch to different software, whereas it's hard or impossible for most people to switch ISPs.

GPRS/HSDPA/3G/4G/5G

Radio spectrum costs providers millions of dollars, and each new cellular protocol increased spectrum efficiency, so upgrading means that providers can support more users with less spectrum. The problem is that most of the "Western" countries still have lots of IPv4 addresses, so there isn't much cost benefit to switching to IPv6. However, China and India both have lots of users and fewer IPv4 addresses, so there is a cost benefit to switching to IPv6 there, and unsurprisingly both of these countries have really high IPv6 adoption rates.

themafia5• 3 months ago

It didn’t take 25 years for SSL.

It wasn't even on the map until 1994. Prior to that it was an ad-hoc mess of "encryption" standards. It wasn't even important enough to become ubiquitous until Firesheep existed.

Even then SSL just incorporated a bunch of things that already existed into an extensible agreement protocol, which, in the long run, due to middleware machines, became inextensible and the protocol somewhat inelegant for it's task. 30 years later and it's due for a replacement but we're stuck with it. Perhaps slow adoption isn't a metric that portends doom.

throwawaymobule• 3 months ago

I think most of the web wasn't encrypted by default until letsencrypt came on the scene just over a decade ago. (I remember a few "free cert" offerings that were entirely manual, and cost you $200 if you wanted to revoke a cert)

It's firmly the default now, and very odd if a site doesn't default to https.

commandersaki2• 3 months ago

Yeah the at least 25 years thing is a cop out. The IPng committee specifically chose the protocol that didn't have a transition plan, and today still doesn't have a transition plan.

I expect we're going to plateau with adoption for a long while now. 50% adoption is meaningless if it doesn't tangibly make a dent in the IPv4 exhaustion problem.

Dagger228• 3 months ago

Well, other than the transition plans that it has and still has. The exact same plans that the other options like TUBA had.

If you ignore those then sure, it didn't have a plan.

kristopolous2• 3 months ago

if it was easier to use and less of a PITA, it wouldn't be taking decades.

9dev18• 3 months ago

If anything, IPv6 is extremely easy to use, especially with SLAAC: On any kind of standard network, you turn on IPv6 on your machine, and, given physical connectivity, bam! You're on the internet.

It only gets complex if you try to micro-manage it.

nslsm3• 3 months ago

So, like ipv4, but you lose the protection and privacy afforded by the NAT?

nottorp4• 3 months ago

especially with SLAAC

Oh no, last time I asked on HN I got 24 to 48 easy steps involving a lot more acronyms than this (please don't repeat them).

IPv6 is easy to use only if you let your one router manage everything and you give up control of your home network.

Edit: again, please don't help. There have been HNers trying to help before, but my home network is non trivial and all the "easy" autoconfiguration actually gets in the way.

kristopolous2• 3 months ago

the internet, in very large volume, disagrees. Am I not allowed to document the widely held common sentiment?

hdgvhicv• 3 months ago

The main complexity of IPv6 is still ha I g to maintain an IPv4 installation. The vast majority of non phone devices do not work in an IPv6 world only because CLAT hasn’t been baked into the OS since the very beginning. It still isn’t a first division tenant on Linux servers, desktops, IoT, or windows. I believe OSX integrates it now

Could with approximately zero services requiring IPv6, the collapsing cost of IPv4 addressing, and it makes IPv6 very much a hidden protocol for phones. When I tether off my phone I get an IPv4 address, the phone may well do a 4:6 translate and then something else does a 6:4 translate. That doesn’t matter, I can still open a socket to 1.1.1.1 from my application.

Had IPv4 been transparently supported IPv6 wouldn’t have taken 30 years and a whole new ecosystem (phones) to get partway there.

rawoke083600• 3 months ago

Honestly... Its more machine vocab than human level vocab.

Ipv4 is jsut about able still to hold in your head, have a convo or more importantly you can: "Shout an ipv4 across the open office floor from your desk to your tech colleague"

If you shout an ipv6 address in public, you jsut seem broken

smolder3• 3 months ago

It's not. I learned how IPv6 worked SO LONG AGO that I really can't understand remaining confusion.

mort96• 3 months ago

It's not complicated because you understand it? Okay then

smolder3• 3 months ago

Not much more complicated than IPv4. There are more bits. The addresses are longer. It's not hard to grasp if you understand the prerequisites to understanding networking in general.

9dev18• 3 months ago

That applies to pretty much any reasonably complex idea. A new system requires effort to understand it. When you've expended that effort, it's not complicated anymore.

I don't understand this sentiment—as if learning IPv4 was enough work on your part, and now you're entitled to networking protocols never changing anymore.

bryden_cruz• 3 months ago

I recently had to set up basic IP-based country detection in Nginx for a project. Parsing and handling IPv4 is trivial. The second I had to account for IPv6 string formats and update the Geo databases to match, the complexity just spiked for no good reason. It feels like we traded address exhaustion for parsing nightmares.

threiw4• 3 months ago

On one of my linux machines the "localhost:8080" did not work after new installation. It resolves to local ipv6 address, while server only listened on ipv4.

After this I go out of my way to disable, remove and nuke ipv6, out of every setup and deployment I do. Ipv6 is already quite complicated, but supporting TWO competing network stacks, with complicated pseudo compatibility, just multiplies unnecessary complexity!

eqvinox14• 3 months ago

Or, you could've fixed your server's configuration. Probably would've been faster than to "disable, remove and nuke ipv6". In general, the mistake is that it says "0.0.0.0" or "0.0.0.0:8080" somewhere where it should really say "::" or "[::]:8080".

(IPv6 sockets by default accept IPv4 connections, unless you disable that either system-wide or on the specific socket.)

By the way, I do agree the colon was a really poor choice for separating the blocks, when it is also used to separate the port number.

orev2• 3 months ago

What you seem to be misunderstanding is that your whole process of nuking IPv6 is more work than studying the issue for a few minutes and then listening on both protocols. Setting a service to listen on a port will use both IPv4 and IPv6 by default, and if yours isn’t means you’re probably already doing something wrong or also have other bugs.

themafia5• 3 months ago

inet_pton/inet_ntop handle AF_INET6.

eviks• 3 months ago

This is not very substantive, but rather procedural, like this example of an answer doesn't tell you much, but tells you the official paper IDs:

Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition.

Why/how did it turn out?

eqvinox14• 3 months ago

Why/how did it turn out?

It is extremely hard (for Brian, but even more so for anyone else, I certainly can't) to give a good answer to that, since you're talking about the absence of utility. People had applications in mind but dismissed them because they either found better ways or it wasn't practical. But that very frequently doesn't result in a "paper trail".

(It's a bit like LLMs having problems with negatives/absences.)

Dagger228• 3 months ago

Try it and see!

  192.168.1.1$ ip link set sit0 up
  192.168.1.2$ ip link set sit0 up
  192.168.1.2$ ping ::192.168.1.1
  64 bytes from ::192.168.1.1: icmp_seq=1 ttl=64 time=0.812 ms

(It works over the Internet too, though make sure your firewall doesn't block protocol 41 and that the packet doesn't get NATed.)

Notice how this doesn't really help you at all. You still need a functional v4 network, you still need v6 support in the kernel on both sides and your programs still need to support AF_INET6 sockets -- at which point, why not just use ::ffff:192.168.1.1 which sends packets without the tunnelling and doesn't need OS support on the far side, or 192.168.1.1 which works with AF_INET sockets and doesn't need tunnelling or any OS support on either side? This is strictly worse than the former option and less compatible than the second.

ExoticPearTree4• 3 months ago

My first IPv6 implementation was in 2010-2011 (memory a but fuzzy). Carriers supporting BGP over IPv6 were few, websites over IPv6 were also scarce.

Fast forward 15 years snd the situation has improved quite dramatically.

IPv6 has some quirks that make it harder to digest.

- link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space

- privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer

- multicast instead of broadcast

- way too many ways for autoconfiguration (SLAAC, DHCPv6)

- no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4”

In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.

hnlmorg9• 3 months ago

The nice thing about NAT is it makes the security model easier to reason about.

By this, I don’t mean it’s more secure, because I know it isn’t. But it is a lot easier to see and to explain what has access to what. And the problem with enterprise is that 80% of the work is explaining to other people, usually non-technical or pseudo-technical decision makers, why your design is safe.

I really do think IPv6 missed a trick by not offering that.

gucci-on-fleek7• 3 months ago

The nice thing about NAT [...] I really do think IPv6 missed a trick by not offering that

IPv6 supports NAT [0], and nearly all routers make it easy to enable. The primary differences compared to IPv4 is that no-NAT is the default, and that it's more heavily discouraged, but it still works just as well as it does with IPv4.

[0]: In the same way that IPv4 "supports" NAT, meaning that the protocol doesn't officially support it, but it's still possible to implement.

eqvinox14• 3 months ago

One good thing about IPv6 is that any reasonable allocation will be large enough to use sizable chunks as functional divisions.

A small company might have a /48. You don't have to be concerned about address space when you just go, ok, first bit is for security zones. Or first 2 bits. Or first 3 bits. Do you need more than 8 security zones?

(Also, ULAs¹ exist, and most people should use them, independent of a possible consideration to not roll out GUAs² in parallel as one would normally do.)

¹ Unique Local Address, fc..: and fd..:

² Global Unicast Address

9dev18• 3 months ago

The price you pay is that it's more difficult to reason about what is accessible from elsewhere, because all devices are represented by your router from the outside, and there are no great ways to opt out of that.

With NAT removed, you've still got the firewall rules, and that's fairly easy to reason about for me: Block anything from outside to inside, except X. Allow A talking to B. Allow B to receive Y from outside.

bladeee• 3 months ago

It is absolutely a thing in IPv6 as well, but why would you do that.

https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...

themafia5• 3 months ago

It's just one firewall rule at the border to block all inbound traffic to a subnet or a range unless related to an outbound connection. Now you have identical security to a NAT. The huge win is you can forget about port forwarding and later just open the ports you need to the hosts you need or even the whole host if required.

Dagger228• 3 months ago

Nope, it doesn't. The security model is based on your firewalls and routing, not on NAT. NAT just gets in the way and makes it harder to understand what's going on.

For example, on a normal home network, if you don't have a firewall on your router then your ISP can connect to anything on your network. Even when they don't control the router and even if you're NATing.

If you didn't realize this then apparently NAT didn't make it easier to reason about after all.

somat• 3 months ago

NAT is a statefull firewall with a trick.

One is exactly as complicated to reason about as the other.

Except on one you don't need the trick.

otabdeveloper42• 3 months ago

But it is a lot easier to see and to explain what has access to what.

"What has access to what" is exactly what computer security is.

throw0101d• 3 months ago

The nice thing about NAT is it makes the security model easier to reason about.

I first heard that relying on the 'moated castle' design of security (firewalls) was bad idea and no longer best practice a decade or two ago, and while inside/outside may be a convenient mental shortcut for security, it shouldn't be relied about.

Sure, sensible people know that NAT ≠ security, but by having private/public IPs I think it makes people's thinking lazy. Every system having publicly routable addresses (but not publicly accessible, due to SPI) would force more folks to actually examine their security controls.

It's too easy to think "ah, this has a 10.x.y.z address, therefore it's inside and safe". No, because most attacks nowadays involve compromised/ing clients, and then running around 10.x networks where people got lazy because these things are on the "inside".

Hikikomori4• 3 months ago

In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”. Those people love their NAT.

Was also designed in the early 90s before security was taken seriously.

ExoticPearTree4• 3 months ago

Was also designed in the early 90s before security was taken seriously.

True, but since then it has transformed into “no one gets in because we have _private_ IP addresses”…

icedchai9• 3 months ago

The real problem is many "enterprises" have people who don't understand networking. NAT was a solution to IP address depletion. This is not a problem we have with IPv6.

If security is taken seriously, I'm sure they can spend a few minutes and learn how to configure a IPv6 firewall that allows no inbound connections. It's basically the simplest configuration possible.

jjav2• 3 months ago

In the enterprise space, if you mention globally reachable address space, the discussion tends to end pretty fast because “its not secure”.

Topic drift, but for younger people who didn't live it, that's how it used to be!

For most of the 90s my workstation in the office (at several employers) was directly on the Internet. There were no firewalls, no filtering of any kind. I ran my email server on my desktop workstation to receive all emails, both from "internal" (but there was no "internal" really, since every host was on the Internet) people and anyone in the world. I ran my web server on that same workstation, accessible to the whole Internet.

That was the norm, the Internet was completely peer to peer. Good times.

icedchai9• 3 months ago

Same! I even had my home network on a public /24.

vrighter• 3 months ago

i still do this today!

thbb123• 3 months ago

Pretty much all tech companies and universities had a drop-in ftp server where anyone could, anonymously, put and retrieve files. It was a collective 'pastebin' useful to exchange information with clients and partners.

On the ftp server of the company I worked for, someone had put a cracked copy of our software for their colleagues to use.

otabdeveloper42• 3 months ago

Good times.

Hope you're sarcastic, because they really weren't. It was a shitshow for decades until we figured out just a bit of a clue about security practices.

BobbyTables2• 3 months ago

The SLAAC/DHCPv6 combo seems really strange to me.

Either IP/DNS/gateway discovery with one or the other could be tolerable. But allowing combinations such as SLAAC for addressing and DHCP for DNS discovery is lunacy.

It’s as if one said, let’s take the most basic and critical step and make it as complicated as possible and explore the combinatorial explosion…

kalleboo2• 3 months ago

The article mentions that DHCPv6 was an afterthought because DHCP itself barely existed when IPv6 was being designed - they were still using things like RARP or BOOTP!

https://en.wikipedia.org/wiki/Reverse_Address_Resolution_Pro...

https://en.wikipedia.org/wiki/Bootstrap_Protocol

teddyh3• 3 months ago

IPv6 has some quirks that make it harder to digest.

Almost every point in your list is wrong.

- link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space

IPv4 has link-local addresses, too. Those are the 169.254.X.X addresses that you see on Windows machines. IPv6 adds nothing new.

- privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer

Well then, don’t use them. Configure the machines with one address each, just like before. If you want the (arguable) advantages of the privacy extensions, they are available, but not mandatory.

- multicast instead of broadcast

IPv4 always had multicast, too. IPv6 is simplified by considering the broadcast concept to be a kind of multicast.

- way too many ways for autoconfiguration (SLAAC, DHCPv6)

SLAAC is just link-local addresses, which you already mentioned above. Did you mean NDP with router advertisements?

If you did, you do have a small point, but DHCP6 is still there like always. IPv6 just offers an additional feature for the simple cases where a host just needs an IP address, netmask and a router address.

- no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4”

That’s the complete opposite of my experience. Almost everything in IPv6 works exactly the same as with IPv4.

patmorgan23• 3 months ago

You're being obtuse. Every point in the original comment is correct, you just disagree they're issues. The original comment also doesn't state they are issues just that they are differences.

• link local addresses

.Auto configuration addresses are in V4 but they are used entirely differently. Interfaces do not have link local addresses if they have a DHCP or statically configured address, in V6 it is extremely common to use a link local address as the gateway, in V4 this basically never happens.

apple4ever3• 3 months ago

> IPv6 has some quirks that make it harder to digest. Almost every point in your list is wrong.

You missed the point and almost every counterpoint in your list is wrong.

> - link local gateway address, makes it hard to understand why the subnet does not have a gateway from the ssme address space IPv4 has link-local addresses, too. Those are the 169.254.X.X addresses that you see on Windows machines. IPv6 adds nothing new.

That's not what the OP said. Note it says gateways. IPv4 when DHCP'd will show 192.168.1.1 for example when it has a 192.168.1.55 address. IPv6 will show fe23::166:8f2c:9a21:96de when it has a 2001:921:61c:aef:78f:7190:1ca2 address, despite the gateway actually being 2001:921:61c:aef::1. So its highly confusing for no good reason.

> - privacy extensions: it is very hard to explain to people why they have 3-4 IPv6 addresses assigned to their computer Well then, don’t use them. Configure the machines with one address each, just like before. If you want the (arguable) advantages of the privacy extensions, they are available, but not mandatory.

While you can configure not use them, by default DHCP'd devices WILL have a bunch. Again confusing for no good reason.

> - no real tentative mapping to what people were used to. Every IPv6 presentation I did had to start with “forget everything you know about IPv4” That’s the complete opposite of my experience. Almost everything in IPv6 works exactly the same as with IPv4.

It's the complete opposite experience for most people, including network engineers.

izacus5• 3 months ago

It is like it is because:

* It was designed by people who didn't have the full picture and were missing representatives from hardware vendors, small businesses, home network admins and a bunch of other people that will be affected by design.

* It was designed by people who didn't consider the cost of migration and the amount of work that would require (see previous point).

* It was designed by people who lived in an ivory tower of "noone will run dual stack for a long time", "everyone will love to run two completely separate network designs".

* It was designed on a premise that end-to-end, fully accessbile devices are something we actually want and won't cause privacy issues.

I think it should be a study material on how standards and designs by commitee can go wrong if they're not headed by people with extensive experience across the industry with enough authority to push for good solutions.

IPv6 tried to do too much (just like many software "let's refactor this legact code") and was done by people who didn't consider all perspectives and costs (again, like many less experienced architects trying to rewrite legacy software).

Paracompact• 3 months ago

Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in {{RFC3513}} but deprecated by {{RFC4291}} because it turned out to be of no practical use for coexistence or transition.

Any tl;dr on why/how the simplest solution imaginable would have been "of no practical use for coexistence or transition"? Granted, I understand the other points make a strong enough case by themselves.

duskwuff• 3 months ago

TL;DR: because it doesn't actually solve anything.

Being able to jam an IPv4 address into an IPv6 packet header doesn't mean you can send that packet to an IPv4-only host and have it be understood. You still need an IPv6 stack on both endpoints, and on all the routers in the middle - and at that point, why not just use IPv6 addresses?

direwolf20• 3 months ago

Also, it already exists. The IPv4 range is included in the IPv6 range. 0000:0000:0000:0000:0000:ffff:0a00:0001 is the official IPv6 representation of 10.0.0.1.

As you can see, it doesn't actually solve anything.

It makes some APIs more convenient! You can pass this address to Linux for an IPv6 socket and it will secretly open an IPv4 connection to 10.0.0.1, so your code only has to support IPv6 sockets to support IPv6 and IPv4 connections.

It seems I've been rate limited to post every 12 hours, instead of five times per three hours. It must be either because I said interpreters don't emit native instructions, or because I said America had to buy TikTok to maintain American propaganda, or because I said you can make money gambling if your bets are the same as insiders. Or maybe I'm being punished for voting. I don't think dang will ever confirm what the reason was. Hacker News is so intransparent.

roenxi• 3 months ago

There was also unnecessary confusion caused by a rather political decision to make IPv6 require support for IP Security (IPsec), which was an immature technology at the time. This was a definite brake on IPv6 deployment until it was dropped after some years.

I don't know anything about the IPv6 situation, but the way this paragraph just slots in so innocently foreshadows some long wordy Wayland retrospective document on why adoption was so slow where someone from deep in the community slips in 1 short "sure we tried to block screenshots and that might have caused some issues with adoption for some users" paragraph in the middle-end. The innocence of the admission is so mild and context-free that it somehow manages to make itself look guilty.

gucci-on-fleek7• 3 months ago

In my experience, the IPv6 protocol is much simpler than the IPv4 protocol. However, the IPv6 tooling and documentation is still worse than it is with IPv4, and dual-stack is inherently going to be more complicated than implementing any single protocol, so I do have some sympathy towards "IPv6 is hard".

For example, the IPv6 packet structure [0] is much simpler than the IPv4 packet structure [1]; SLAAC [2] is much simpler than DHCPv4 [3]; IPv6 multicast [4] is much simpler than IGMP [5]; IPv6's lack of NAT simplifies peer-to-peer networking compared to IPv4; ULAs [6] prevent the annoying address conflicts you get with IPv4 [7]; etc.

[0] https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header

[1] https://en.wikipedia.org/wiki/IPv4#Packet_structure

[2] https://en.wikipedia.org/wiki/IPv6_address#Stateless_address...

[3] https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Pro...

[4] https://en.wikipedia.org/wiki/IPv6#Multicasting

[5] https://en.wikipedia.org/wiki/Internet_Group_Management_Prot...

[6] https://en.wikipedia.org/wiki/Unique_local_address

[7] https://stackoverflow.com/a/52374482/30512871

j16sdiz3• 3 months ago

ULA give more trouble than what it solves.

Almost all computer have multiple interface (virtual or not). Application now need to know which interface the destination is on, and there is no easy data structure to store the interface

eqvinox14• 3 months ago

You're confusing ULAs (Unique Local Addresses) with LLAs (Link-Local Addresses).

(ULAs don't need the interface specified.)

ULA: fc..:… and fd..:…

LLA: fe80:…

[ed.: By the way, sin6_scope_id is where the interface identifier is stored in struct sockaddr_in6. So, basically every single IPv6 address object you're handling has the field for it.]

gucci-on-fleek7• 3 months ago

ULA give more trouble than what it solves.

How? They're essentially the same as IPv4 addresses; the only difference is that there are way more of them, so address conflicts are much less likely.

Almost all computer have multiple interface (virtual or not)

Sure, but that's the case with IPv4 too: my cell phone has one IPv4 address over WiFi and another over cellular, and my laptop has one IPv4 address over WiFi and another over Ethernet.

Edit: Ah, I think that eqvinox's comment [0] is what you were getting at here. And yeah, I agree that LLAs are kinda confusing and annoying. The difference is that LLAs aren't routable [1] and don't have an IPv4 analog, while ULAs are routable and are mostly equivalent to IPv4 addresses [2].

[0] https://news.ycombinator.com/item?id=47814154

[1] https://en.wikipedia.org/wiki/Link-local_address

[2] https://en.wikipedia.org/wiki/Unique_local_address

peanut-walrus2• 3 months ago

I've always found the most complicated part of IPv6 to be address scopes and source address selection. The fact that one interface can have any number of addresses in different scopes and prefixes complicates things a lot.

Another thing that will always trip up new IPv6 network engineers is solicited-node multicast. You know the theory, computers talk to ff02::1 for neighbor discovery and then you hop onto a real network and see none of that actually happening.

And probably the most complicated thing for network engineers - how to set up firewall rules if machines are constantly changing their addresses.

For developers and security people - just parsing and validating v6 addresses is a whole bunch more work, but at least for this, the tools are available to help you now.

bewo001• 3 months ago

An interface can have many ipv4 addresses as well. It's just not that common, so many people believe they'd need vlans to achieve that.

peanut-walrus2• 3 months ago

Yes. But it's quite an uncommon setup. For IPv6 multiple addresses is the default.

wongarsu3• 3 months ago

A lot of it seems to boil down to "IPv6 was too early". Had IPv6 been developed a couple years later DHCP would have been mature, and SLAAC would have never been invented (since DHCPv6 is fairly obvious when you have good experiences with DHCP). Also it would have given all the alternative protocols (especially OSI) time to try (and likely fail) to gain traction, freeing IPv6 from the obligation to cram in all of their features. IPv6 could have picked a much smaller set of features that were proven useful by other protocols, then swoop in as the much simpler upgrade from IPv4 than any of the competitors

grandinj2• 3 months ago

A couple of years later ipv6 became unnecessary. A big driver for ipv6 at the time was routers not being able to manage the increasing size of the core routingtable. Then 2 years later betterhardware and routing table compression became available and ipv6 became unnecessary.

Dagger228• 3 months ago

Uh, no it didn't? Routing table size is still something of a problem, especially as v4 continues to fragment more and more, but also the main driver was insufficient IP addresses in v4 and that problem hasn't even slightly gone away.

wongabu5• 3 months ago

There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network.

inb4 no you can't have all lan devices have multiple ipv6 addresses and choose for themselves, typically 1 WAN is cheap and the second WAN is expensive/slow and should be used only for WAN1 failover

Inb4 no you can't just advertise new RA, devices on lan can takes minutes to update.

On ipv4, NAT+changing route on router just works, 1-2 seconds failover.

mrsssnake• 3 months ago

IPv4 has exact same problem, the NAT is working here because devices does not actually have proper Internet connection, all connections are terminated on NAT and reassembled after.

Actual solution could be extending TCP and UDP or make a new transport layer procotol that handles changing addresses, similar to what QUIC do. But we cannot do it exactly because things like NATs existing, thus QUIC build was build on ossificated UDP. Imagine if instead of IP+port a connection use unique per-connection hash to persist IP addreses changing. No more trying fighting to keep the IP the same.

wongabu5• 3 months ago

Ipv4 does NOT have this problem. The typical setup is always NAT for ipv4 lan, so external address can be changed with minimal disruption.

All ipv4 apps that require hole punching assume they will need to "discover" the external address anyways, for every new p2p connection.

In contrast to the vast majority of ipv6 apps which assume their ipv6 address is identical to external ipv6 address, as this is(was) the main marketing point of ipv6 - directly addressable end points.

icedchai9• 3 months ago

The actual solution is network prefix translation. You effectively NAT the primary network when failed over to the secondary. See https://docs.netgate.com/pfsense/en/latest/recipes/multiwan-... for an example.

wongabu5• 3 months ago

That's one ugly hack, which assumes (1) WAN1 has static ipv6 (the typical SME has dynamic DHCPv6 address...) (2) all the devices will behave correctly when running on NPT on failover WAN2. Many devices do not know about NPT which is basically NAT for ipv6, and break on p2p protocols like voice, video, streaming. They'll send the wrong NPT address to the other side, which try to connect back to the WAN1 address, which is down because of failover.

yjftsjthsd-h3• 3 months ago

Can you just NAT66?

wongabu5• 3 months ago

Have you tried it? NAT66 implies using fd00::/8, which then gets deprioritized in all devices below ipv4, in accordance with RFC 3484. The end result: all devices revert to using ipv4 on dual stack lan.

Ipv6 is fundamentally broken for failover scenarios.

JackSlateur• 3 months ago

Pretty sure BGP exists. NAT, also.

wongabu5• 3 months ago

BGP is not for everyone: get an ASN, your own prefixes, and run BGP. Compare that to the simplicity of ipv4 NAT.

Ipv6 NAT66 is fundamentally broken, see sibling comment.

bigfatkitten3• 3 months ago

If you ever find a cellular carrier who will do BGP over LTE for a retail customer, let me know.

bigfatkitten3• 3 months ago

There is no working solution to ipv6 dual WAN failover, 30 years later... A critical design flaw that was simply ignored by the designers despite being used in almost any SME network.

One of the major issues with IPv6’s design and development is that the people who designed it do not operate networks, nor do they build networking products. They literally fly around the world to committee meetings for a living.

Critical use cases like this are missed and/or ignored because they do not fall within the committee members’ ivory tower world view.

montag• 3 months ago

My problem with IPv6 is that I can't double click 2001:db8::1428:57ab to select the entire address. It's a silly complaint but representative of real ergonomic issues.

p1mrx• 3 months ago

It would be pretty straightforward to change the text selection rule, so that double-clicking anything matching the syntax of an IPv6 address selects the whole address.

The hard part is to find all the places to repeat that change, and convince the code owners to accept it. Probably start with a standard analogous to RFC 5952?

zbentley• 3 months ago

This is a great idea. To slightly sidetrack things: I think updating computer UI text selection behavior to not break click/snap-to-next selectable words on colons without padding spaces in general would be a good thing.

"A: B" would still click-select either "A:" or "B", but "1:2" (a ratio) would select the whole thing, as would "small:med:large" or an ipv6 address. In other words, I think that, in practice, English writing has assigned semantic significance to space-less colons in enough cases that text selection systems should reflect that.

Though I'm not sure RFCs are going to drive general GUI behavior--they won't "MUST" it, because that's overstepping, and I'm not sure GUI/OS-text-selection-functionality maintainers will be persuaded otherwise.

tsoukase• 3 months ago

This is the most pro-IPv6 comment I could ever imagine. I am more persuaded now than by the IPv6-is-easy guys all these years.

petee• 3 months ago

Fwiw opera mobile on Android selects the whole address there when i long-press

rao-v3• 3 months ago

At a high level one of the sad things about IPv6 is that it surrenders a wierd, valuable and emergent property of IPv4 for the average home user in $random_country:

IPv4 addresses in logs are not super helpful in tracking a specific person and household’s behavior long term (NAT, reuse etc.)

Almost every end user oriented IPv6 deployment makes it significantly easier to use IPv6 addresses to persistently track individual machines (ie individual people) and map them to a household (yes I’m aware of RFCs 7217 and 8981, I’m mostly talking about long term stable prefixes).

How much of a real concern this is is debatable but it’s perhaps a little bit unfortunate.

doubled112• 3 months ago

At home, my external IPv4 address was the same for extended periods of time even though I never paid for a static IP. You could have figured the traffic was coming from the same location.

The one external IP to many internal devices relationship does help with privacy.

But once you enable those IPv6 privacy extensions, I have so many devices bouncing between IPs I’m not sure how you’d even know how many devices I have, let alone which device is which.

rao-v3• 3 months ago

My experience is that this is largely true only of the biggest ISPs in the US and Europe that were around in the 90s and have IPv4 in plenty. In other countries or even with other ISPs I see fairly frequent turnover.

Agree it’s not the biggest deal but it is a pity and something the protocol stack around IPv6 should support (daily/weekly randomizing of prefix unless someone needs the stability). The vast majority of modern devices and usecases get no additional value from being stably addressable from the internet.

RiverCrochet• 3 months ago

Most of the bitching about IPv6 is from those who really, really want IP addresses to identify machines or users. IP addresses (including IPv4) were never intended to do that and it was never a good idea to put them in that position.

There was a time when most devices had 1 network interface and didn't move. But that was never a guarantee. People thought it was a guarantee when your $400-in-1988-dollars Madge ISA full-height full-width token-ring NICs with dangling AUI dongles next to your tank of an ST225 hard drive were a thing, but we're past that. Today most things that aren't servers have at least 2 - wired/Wi-Fi for laptops, Wi-Fi/cellular for phones. You can talk about NAT and security and mapping all you want, but if I can bypass your corporate internal network security simply by turning off my phone's Wi-Fi, yet still get to your resources - then NAT is a legacy chore that IPv6 makes unnecessary.

menotyou• 3 months ago

My IPS changes my prefix once in while. I consider this a privacy feature, not a bug.

Now I find myself in a situation that my devices are not reachable anymore as when the IPv6 address changes and both DNS entries and firewall need to be updated each time when the prefix changed (In between connections break, but this might be a lesser problem)

As far as I understand the only solution which does not include some complex scripting of ip change detection and automatically updating the firewall rules is to use NAT66 and ULA. But even then I have a protocol whose most advertised feature is not to rely on NAT and puts mit fast in a situation in need to use NAT. And the privacy extension of every device or the devices using SLAC and not DHCPv6 are problematic.

IPv6 is just not able to steup efficiently for where IP addresses are changing. Not with moving mobile devices, not in wifi environments with multiple access points, not with changing prefixes, not in failover scenarios.

Bottom Line: I disabled IPv6 again here without any intentions to look for complex workarounds. All outbound traffic is now IPv4 again. IPv6 is providing no benefit but causes additional problems over IPv4 due to issues with the design. I am waiting for IPv7 (or whatever will be the next successor of IPv4) will arrive.

Dagger228• 3 months ago

Are you talking about reaching the devices from inside the network, or outside?

If inside then you don't need NAT66 and ULA, you just need ULA. Use both ULA and the ISP GUAs on the network, and do your internal connections over ULA. If outside, then NAT66+ULA doesn't help because connections from outside will still fail until you update DNS for the new prefix.

NAT66 doesn't help in either situation, so why do you think you need to use it here?

automatically updating the firewall rules

You can probably structure your firewall rules to not rely on the prefix, e.g. by doing "connections from WAN to LAN where the address matches ::42/-64" -- you might to write it with a mask instead (::42/::ffff:ffff:ffff:ffff), which looks awful but works fine. There's no point in putting a specific prefix into the rule if you're just going to change it to match the network anyway.

ksec2• 3 months ago

Getting IPv6 to about 50% deployment has taken more than 25 years. Any alternative or new proposal would be the same.

That is oversimplified a few things. The 50% deployment is largely Mobile Phone + Cloudflare and India. ( Not sure about China ). Outside of that things aren't that different from a high level overview.

You could have 50% deployment in less than 10 years if 6G Mobile Phone mandate the use of let say IPv8.

jordiburgos• 3 months ago

I would be easier to accept if it was just an extension of IPv4. Make the addresses longer but keep the types A,B,C,D. Keep the network address x.x.x.x/y. That way everybody will be familiar with it and change will be done smoothly.

tiberious726• 3 months ago

It basically did, just in hex...

vaylian• 3 months ago

The headline is not confirmed in the text:

First of all, IPv6 really is a conservative design - it doesn't change the basic IP model of connectionless packet switching with topological addresses.

api3• 3 months ago

It’s not. It’s IPv4 with more bits and some changes to Ethernet level lookup.

The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.

ninkendo5• 3 months ago

The changes to Ethernet lookup mandate that you have a link-local address in addition to your “real” address, and this starts the ball rolling on the idea that machines have multiple IP addresses in general. Which makes privacy addresses commonplace, ULA+GUA addresses on the same machine, etc.

I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere. IP-based access control becomes impossible (not that it was ever a great idea in the first place), reverse DNS lookups become irrelevant, seeing IP’s in logs no longer tells you “what machine connected here”, it’s overall a big change in mental model.

But then you get over it, stop making assumptions that you can rely on IP addresses for knowing things about a host, and the rest of it is fine.

doctorpangloss3• 3 months ago

I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity,

a little over half the bytes of a typical IPv6 visitor's address is comparable in identification to what all four bytes of an IPv4 address tells you

simoncion11• 3 months ago

I think this is the biggest change with IPv6: that a machine’s IP addresses is no longer its identity, and you can’t easily predict what address will be used when connecting somewhere.

Can't you unset the "Use autonomous addressing" bit and set the "Use DHCPv6 for addressing and other config" bit in your RAs, and then refuse to hand out anything other than DHCPv6 Normal Addresses? Or do OS's ignore the fact that Temporary Addresses are an entire other category of DHCPv6 addresses and just go off and make their own "privacy addresses" off of the advertised prefix in the RA... ignoring the router's command to not use SLAAC for addressing? [0]

[0] Yes, I'm very aware that Android doesn't support anything that DHCPv6 provides other than getting an entire damn prefix delegated. For the duration of this discussion, let's ignore Android.

tardedmeme28• 3 months ago

Nothing in v6 stops you giving a machine a single stable address (plus link-local). Every server on the internet has one. You can also bind a socket to a specific source address if that's what you want, because the recipient is IP-filtering.

formerly_proven• 3 months ago

If it actually was v4 with more bits and different ARP it wouldn't take 30+ years to be deployed.

tardedmeme28• 3 months ago

It's the more bits that are the problem. Anything with more bits is incompatible with the whole internet and anything that's incompatible with the whole internet won't be deployed quickly if ever. NAT is way worse than IPv6 but it got deployed quickly because it was compatible.

dgoodell• 3 months ago

IPv4 + all the other stuff you need to actually make it work in the real world actually seems more complicated than IPv6 to me.

Maybe they’re comparing the minimal implementation on a home network. But even then I’m not sure the claim holds up.

People learned IPv4 when they were younger in a more incremental manner and take it for granted now.

api3• 3 months ago

V4 plus one or more layers of NAT and all that junk objectively is more complicated, but it’s the devil people know.

Ekaros6• 3 months ago

ARP and DHCP really look really dirty whenever I look at them. Like pretty bad designs overall. From more neutral viewpoint it feels that whole stack would be better with something else than these clear hacks.

Spooky23• 3 months ago

When I turned IPv6 on on my spectrum connection i ended up with like 4 different interfaces I didn’t need and broken local DNS.

convolvatron4• 3 months ago

the intent behind the ipv6 spec was to remove dhcp as a requirement for establishing layer 3 connectivity. there was a generalized notion at the time that other service discovery (dns) would be handled by a more graceful multicast protocol. that was a very reasonable position to take.

but operational inertia got in the way. I don't think people really wanted to think about what a dhcp-less world would look like, even if it removed the requirement to manage a central service and the associated configuration.

this was kind of ok. but then things got ugly. people wanted to be able to get assigned prefixes dynamically from their upstream provider that they could subnet themselves. because we don't think about these issues architecturally anymore, someone put that function on dhcp. and since we don't think about these issues architecturally anymore no one really realized that that would require _another_ protocol on the inside of that boundary to manage assignments in the providers space.

and now we don't even have the option of depreciating dhcp gracefully.

doctorpangloss3• 3 months ago

SLAAC and DHCPv6 actually make a ton of sense, along with the other features of IPv6. I think you need a lot of experience in both networking and applications, at many scales, to understand the design decisions and appreciate how useful they are in which contexts. That said, you could publish a clear playbook for an ISP of residential Internet for ipv6 adoption, it wouldn't change much, because they are not deciding to adopt ipv6 based on either its aesthetics or its technical merits.

kazen443• 3 months ago

SLAAC is probably one of the better improvements of IPV6. DHCP breaks down at scale. Managing many DHCP prefixes becomes a massibe pain, SLAAC is far more scalable, far more easy to make redundant if you have redundant gateway's and protocol wise is really simple.

evilmonkey19• 3 months ago

Personally, i feel it is complicated because ISPs are highly afraid of trying it. I understand that such novel technology would be risky to use. But after 20+ years there are still many countries, like Spain, which are barely using it. After that much time has passed, it is already well battle-tested. At this point, you don't want to make the move either because you are too afraid of anything or you have commercial reasons.

I believe Telefonica has reasons to not use IPv6... Although in the long run is turning to be a bad decision. Look at digi :p

api3• 3 months ago

IT and telecom tend to have an ultra conservative if it’s not broke don’t fix it attitude. It won’t get deployed until enough customers ask for it or it’s required for something important.

izacus5• 3 months ago

That's because they actually get paid for providing a reliable service, not for ipv6.

tryauuum• 3 months ago

I think they are not afraid, they just see 0 reasons to

without IPv6: everything works already, your customers can access any website

with IPv6: ...what are the benifits to them? they still have to provide IPv4 to customers or do some ipv6 to ipv4 translation to make sure ipv4 websites still work

(I've never worked at an ISP so my opinion might be useless)

johncolanduoni6• 3 months ago

There are some reasons, which is why you do see IPv6 use increasing. IPv4 exhaustion means that almost all mobile (and in some countries landline) internet connections have to access the IPv4 internet through Carrier Grade NAT. ISPs have to buy the equipment to operate these and pay for their maintenance, and they have to do so in proportion to how much traffic is stuck on the IPv4 internet. At a certain point making the necessary investments to send more traffic over IPv6 end-to-end becomes a better bet than continuing to maintain a growing CGNAT stack.

The tough part is that while ISPs can largely control whether their mobile and residential users have IPv6 available they can’t really do so for their business users, let alone arbitrary website operators they have no relationship with. So the reality is that everyone is going to have to maintain both 4to6 and 6to4 basically forever. But as it becomes less common it’ll no longer need to be especially fast or efficient and the costs to operate it will come down.

da_chicken2• 3 months ago

I think they are not afraid, they just see 0 reasons to

This is a big part of it. Apart from extra addresses, it offers remarkably little benefit in terms of networking features from an operational management perspective. It sounds like it should be better when you look at the features, but, in actual operation the features don't really offer that much.

Further, there's the general problem that for some reason the network equipment manufacturers seem to think that because you don't frequently need NAT that now you don't need to have a stateful firewall just always on by default on a network edge device.

Plus the general confusion among tech neophytes that NAT itself is offering actual security features, so that a stateful firewall is a downgrade. This is such a fundamental misunderstanding that you can't even communicate with a person that believes it to be the case. I fear that this confusion will remain with us for decades. I'm sure me even mentioning it will spawn a whole thread of people vehemently disagreeing, because there is always at least one.

This is coupled with the fact that the addresses are just ugly. Like, I'm sorry, but unless you're exactly an electrical engineer, the IPv6 addressing scheme is difficult to remember. IPv4 has the same problem -- the magic numbers are only easy to remember if you have memorized the binary values, too -- but it's really only a handful of things to remember in comparison. Hex values are just not as easy to read or remember compared to decimal numbers. So even though IPv6 isn't harder to use, it feels like it's much harder to use.

tonymet3• 3 months ago

it’s the cost of dual stack. The transition from ipv4 to dual stack to ipv6-only goes from low cost, high cost, moderate cost.

There is little value to run dual stack.

Find me a business that would like to spend a lot of money on something of little value.

djha-skin7• 3 months ago

Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is.

For this reason, at every shop I've ever worked at, the intranet is ipv4, often with ipv6 disabled, with dual stack on the load balancer for ingress traffic. Note, I do not set it up that way: it comes like that when I've arrived.

josephcsible• 3 months ago

You can do NAT on IPv6. I've personally done so with both ip6tables and pf.

selectodude• 3 months ago

https://www.juniper.net/documentation/us/en/software/junos/n...

Galanwe2• 3 months ago

Its not just NAT, it's also DHCP. Somehow the nerds creating IPv6 decided to not only add bytes (which is what people wanted), but also "fix" DHCP and NAT, which nobody asked for.

simoncion11• 3 months ago

Its not just NAT, it's also DHCP.

I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003.

As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.

thayne5• 3 months ago

When ipv6 was first created DHCP and NAT were new and not widely deployed. They weren't trying to "fix" them, they solved the same problems independently.

And if you need NAT or DHCP, there isn't any reason you can't use them with ipv6. DHCP6 had been around for a long time.

LambdaComplex• 3 months ago

What purpose do you have for NAT other than putting it where you should actually be putting a firewall?

djha-skin7• 3 months ago

Obfuscation. By inspecting packets coming from my network now you can tell what MAC addresses are in my network and also internal network topology. It's part of the reason your cell phone feels the need to randomize its MAC.

Veserv2• 3 months ago

1. IPv6 does have NAT [1], NAT66.

2. NAT is totally orthogonal to IP and addressing.

3. NAT (as in transparent packet modification to rewrite addresses) is utterly idiotic. Ephemeral, anonymous address allocation with inbound filtering is smart, but transparently rewriting packets to do that is one of the dumbest possible ways prone to horrible compatibility and ossification issues as has been proven empirically.

[1] https://www.ietf.org/archive/id/draft-mrw-nat66-00.html

djha-skin7• 3 months ago

Are you a network engineer?

vlovich123• 3 months ago

What stops you from using NAT66 (full NAT) or NPTv6 (prefix translation)?

zadikian30• 3 months ago

You can do it, it's just not default, which does matter too

djha-skin7• 3 months ago

I am reading about ipv6 nat. I guess it's possible but discouraged?

This contention point confuses me. I consistently get downvoted for this opinion, and I've seen contrarian voices online, but I have yet to meet an actual datacenter network admin who disagrees with me.

Hikikomori4• 3 months ago

I am one, also disagree with you. Ipv6 nat is possible. I dont find nat particularly useful inside a network and dont use it unless strictly required to solve a problem like shared internet access or overlapping IP addresses. Isolation is best handled with separate physical networks, vlan or firewalls.

KaiserPro4• 3 months ago

Facebook uses IPv6 virtually everywhere. They have NAT for ipv4 in dual stack (usually only on certain desktop machines), but not for IPv6 as that defeats the usefulness of it.

virtually all the datacentre is exclusively IPv6. they kinda have NAT in the sense that all the web proxies at the edge terminate the IP connections with the outside world, but thats higher up the stack rather than on the IP level.

However I never dealt with the edge stuff, as that was far away from what I was doing.

tardedmeme28• 3 months ago

It's totally possible and it's totally discouraged. We are not the internet police on HN, and neither is the IETF. If you want to do weird stuff on your own network, you can and you get to keep both pieces.

alfons_foobar2• 3 months ago

NAT is a crutch to circumvent the problem of "there are not enough addresses for each device".

I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).

djha-skin7• 3 months ago

Everyone I've talked to with this opinion are typically mobile devs thinking about cell phones. Ipv6 works great there, but NATs are often used in corporate networks for isolation and in particular obfuscation. You can't tell what's behind a NAT by inspecting traffic coming from inside it like you can with no NAT networks. Some of the networks I administrate are contractually obligated to be so isolated.

KaiserPro4• 3 months ago

but why do you want NAT? to hide whats in the datacentre?

I mean thats what reverse proxies are for, if you're that worried.

NAT doesn't give you anything useful, apart from the veneer of security. Sure it feels like your safe because there isnt a direct routable link between host A and the outside world, but thats not actually true.

If you want that, then you need firewalls and reverse proxies, even in IPv4.

icedchai9• 3 months ago

What exactly do you need NAT for with IPv6? Presumably, if you are operating an actual datacenter, you have a /48 or more.

NAT for IPv4 is a workaround for the scarcity of publicly routed addresses, nothing more. It bought us decades.

NAT for IPv6 does exist, but it's more often done with network prefix translation. If you want "security", you set up a firewall.

tardedmeme28• 3 months ago

No ability to NAT in V4 either - it was hacked on top. And you can run hacky NAT in V6 too. If you really, really, really want to.

seanalltogether• 3 months ago

personally I just hate this -> http://[0123::4567]:5000/whatever

zhdc1• 3 months ago

This. It’s ugly.

All of talk about the technical merits or demerits misses the point. I can spout of a dozen or more memorized IPv4 addresses. IPv6? Good luck.

simoncion11• 3 months ago

There's nothing stopping you from using memorable ULA prefixes on your LAN [0] and requiring the use of DHCPv6 for addressing so that each host gets a host part that is easy to remember. Hand-selecting your ULA prefix abandons the collision-resistance that you get from using The Technique to generate one, but if that's something you don't care about, then it's something you don't care about.

Plus, manual address assignment is just as viable in an IPv6 world as it is in IPv4.

[0] fd00::/64 is quite easy to remember, as are fd00::1 and similar.

hackthemack7• 3 months ago

I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say that I do not like ipv6 because it tried to fix multiple accumulated problems. I know! How contrarian! How can you be against trying to fix things. But all of those issues made ipv6 a dual stack solution that replaced ipv4.

Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization.

Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized

Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).

Plasmoid2• 3 months ago

keeping backward operational compatibility

It is not possible to be backwards compatibility with a larger address space

sethops1• 3 months ago

And yet 50% of the internet is using CGNAT just fine. The extra bits are just in a different place.

hackthemack7• 3 months ago

You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do.

But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.

izacus5• 3 months ago

This is a fake argument. Noone is arguing for backwards compatibility.

But there was also no necessity to demand reshaping networks and changing address assignment in a way that made migration extremely work intensive and hard to deploy in parallel.

Ekaros6• 3 months ago

How you would have implemented backward compatibility? I am interested to hear the general technical details of how this could have been possible.

I am mostly interested in two basic scenarios. With expectation that only on one side is any changes made. Host from new addressing scheme connecting to old one and receiving data back. Host from old addressing scheme connecting to one in new one and receiving data back.

fweimer• 3 months ago

There was a proposal called SIP that mostly focused on increasing address length (it got published as a historic RFC eventually): https://www.rfc-editor.org/rfc/rfc8507

It still had the problem that it made it harder for middleboxen (compared to IPv4) to look at port numbers.

bell-cot• 3 months ago

Short answer: Too many cooks in the kitchen, and too many of 'em motivated to make it more complicated.

A computer standard that is still widely avoided almost 30 years after it became official is a computer standard that should have been tossed in the bin before the ink was dry.

tardedmeme28• 3 months ago

no it's just wrong. V6 isn't complicated. It's V4 with longer addresses and a slightly different field layout.

amelius3• 3 months ago

Just adding bits to the address isn't as simple as it seems.

They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.

Dylan168073• 3 months ago

You can add bits to your own systems fine.

When you want your packets to work on other people's routers, it stops being fine.

amelius3• 3 months ago

If that means those other people cannot reach the internet, then I'm sure those people will fix that faster than anything ever fixed before.

throw0101a5• 3 months ago

They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.

Ah yes, the old IPv4 with 'just' adding more address byte(s) idea ("IPv4+"):

So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)

You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:

* update the IP stack (like with IPv6)

* tell applications about new DNS records (like IPv6)

* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)

You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.

Deploying the new "IPv4+" code will take time, there will partial deployment of IPv4+ is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:

* https://en.wikipedia.org/wiki/Happy_Eyeballs

(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)

Meanwhile, if you have a database it's fairly trivial to add a new field with a four-digit year, and since you're probably only using the data internally, so your co-ordination problem is generally with-in one organization. The co-ordination problem with a new Internet protocol is global.

zadikian30• 3 months ago

I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it:

  Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition.

The practical use would've been going all-in on those, making it as easy as possible for users to switch. But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT, and 6to4 was bolted on in a way that never worked very well.

The thing is, their objective wasn't just to add more bits, it was to defrag the old v4 routes. If you did it the "just add more bits" way, once everyone is on v6 but with the old v4 /32s, the new address space for sale is underneath those. Maybe there'd be a way to defrag afterwards in a separate effort.

Dylan168073• 3 months ago

Going all-in in what way?

The only thing I can think of is making it easier to run your local network v6-only. But if you're translating at the router like that, you don't need any particular mappings.

zadikian30• 3 months ago

I've clarified under another comment what I meant by that

johncolanduoni6• 3 months ago

How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?

zadikian30• 3 months ago

Copy-paste the v4 blocks into v6 space under a common prefix, let's say 4::. Routers and software add ipv6 support (as they already have), but you only use 4::. Now once a user wants to switch, it looks the same. I'm still on NAT and DHCP. If I'm hitting Google.com on ipv6, I still use DNS4 and get 142.251.214.110, it actually sends to 4::142.251.214.110 takes the exact same route.

Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else.

You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.

doctorpangloss3• 3 months ago

they have no point. some random aesthetic aspect of a standard is not why it does or does not get adopted. it's an evolutionary standard that offers no direct incentives for adoption.

the real obstacle was enterprise sales, that is, someone had to pay Microsoft, Google, Amazon, etc. as a major customer of theirs to implement correct IPv6, which takes time. the people at Microsoft working on ipv6 for customers, they're only going to implement the parts that customers need, they're not going to proactively discover all the bugs and fix everything. this is true about everything, i'm not saying anything that unorthodox, except...

the reason we're talking about ipv6 now is, in a post LLM world, it is now possible to take a well written and thoughtful spec like ipv6 and Just Do It. you don't have to wait for a customer relationship to do it.

zadikian30• 3 months ago

Despite the lack of incentive for some, it's gotten pretty far. Pretty much every network device and host supports it in a minimal way. It's just that people/corps don't want to switch because it introduces a lot of risk and changes in unexpected areas. Like you can fully understand the spec without knowing what the routes and reputation will look like.

simoncion11• 3 months ago

But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT...

Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist.

It took something like a decade for IPv4 to get DHCP, and I don't know how long for it to get NAT, and yet I don't hear people saying that IPv4 has no default mechanism for address autoconfiguration or network address translation.

[0] ...by everyone except Android, of course...

zadikian30• 3 months ago

The defaults determine what like 95% of users end up actually using, even if they have their own preference. Like you said, even if I wanted to use DHCP6, Android won't use it. My router also doesn't support it.

zadikian30• 3 months ago

Want to add, it's not too late to do this on top of the ipv6 we have today.

speedgoose5• 3 months ago

I installed a new bare metal server from a european cloud provider this week.

Both my clean Debian and the rescue system couldn’t reach internet through IPv6 despite getting an address through DHCP.

I immediately permanently disabled IPV6. I usually do that pretty late in my installation scripts anyway.

I understand the perfect solution didn’t exist and still doesn’t exist, but it’s frustrating. I wish IPv6 could work reliably, not only on major CDNs, and that is appreciated. Then IPv4 would be a vanishing memory.

MaKey5• 3 months ago

You could have spent a bit of time on debugging the issue. This would have been a great learning opportunity.

Hackbraten• 3 months ago

It's supposed to Just Work on clean and rescue systems. Otherwise, it's a regression with respect to v4. The fact that it doesn't work is evidence that someone has been doing something wrong. The user at the receiving end of this clusterfuck is not that someone.

speedgoose5• 3 months ago

I agree, but debugging IPv6 issues is pretty far down on the list of things I want to learn.

ajb• 3 months ago

The problems of IPv6 deployment are ones of incentives, not design.

Increasingly, the vast majority of services are accessed via the service cone of various CDNs and IAAS providers directly at edge servers local to them, and at some point it may be that the industry decides that it's not worth providing ordinary internet users the ability to talk to each other directly at all. At which point, we might just as well have stuck with IPv4. I don't particularly like that outcome, but it's possible.

t435625• 3 months ago

I think they worked that out long ago - that segmenting users has no downside for them and IPv6 has minor upside. It's only mobile devices that help us but I'm sure there will be kinks in the chain that don't get fixed.

tonymet3• 3 months ago

Any address length greater than 32 would create all the coexistence and transition problems we have experienced since 1994

This is the author’s assumption and not a conclusion. Why did the other designers even bother if this was the case?

tardedmeme28• 3 months ago

Because they didn't realize how that was the fundamental problem.

There are some designers who knew their system would be incompatible but thought it was interesting enough to design anyway, like RINA. There are other designers who just didn't realize why this was a problem, like ipv8. The ipv8 designer is currently berating the NANOG (north america network operators group) mailing list for not already supporting ipv8 on all networks. If it's compatible then why do they need to do anything to add support, eh?

People get emotionally attached to the name "IPv6" being bad, and don't realize how putting the same stuff in a different protocol makes that one just as bad, but without the 30 year head start. If a new proposal is about the same as IPv6 but isn't already supported by most equipment, then wouldn't it be better to use IPv6 instead?

tonymet3• 3 months ago

some of the alternatives were simpler and deliberate attempts to reduce the scope of the migration problem. You can’t say “all approaches would have suffered the same migration effort” as if it’s a given. That’s like saying UTF8 and UTF16 had the same migration effort because they both tried to migrate from 1-byte code points. UTF8 was way easier.

dreamcompiler• 3 months ago

I almost wish NAT had never been invented. It's a kludge that effectively added 16 bits to the IPv4 address space and delayed IPv6 as a result.

thayne5• 3 months ago

And it added those 16 bits in a way that causes a lot of problems

PaulKeeble• 3 months ago

CGNat even more so because its added ~16 more bits and taken away full functioning connections form the ISP customers to do it.

zadikian30• 3 months ago

If/when everyone is forced to leave ipv4 due to address+port exhaustion, it's possible that ipv6 isn't the replacement.

t435625• 3 months ago

I think we've been shunted into an alternate universe by NAT - one which reinforces the power of large companies because we essentially cannot communicate computer to computer without going through some service.

As for security.........are we really that secure running code in our browsers that we downloaded from who knows where? Is nat really saving us?

And now here we are with IPv6 and the real age of the network could begin.

tardedmeme28• 3 months ago

Odd that all these pro ipv6 top level comments are greyed out.

t435625• 3 months ago

Well, there's some food for paranoia :-D.

sylware• 3 months ago

Core IPv6 is not.

Fabricio202• 3 months ago

Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the address to group it back into the /64 and alot of switches and routers that are already expensive still have very low limits on LPM memory banks.

Expensive switch at work we have can only do 3000 route entries for example on ipv6. If we did /128s it's basically infinite though, because it goes from a LPM to exact match, which has much much more memory available.

Doesn't help as well that for example, to be able to do SLAAC or even DHCPv6 (which barely works reliably in my experience) you need to do a /64 at minimum, those mechanisms dont even work otherwise, so for ISPs who can easily have more than 3000 downstream customers doing routed ipv6 is such an increase in hardware cost vs just doing NAT which they were already doing anyway.

kstrauser4• 3 months ago

Why on earth would you ever want to route something smaller than a /64? At the ISP level, you'd only be concerned about your customers' /48 or maybe /56 networks.

simfree2• 3 months ago

OP seems to want to route /64 or larger to each customer, but can only have 3000 total entries larger than /128 in the expensive routers his firm owns.

Essentially the hardware doesn't support scaling a /64 or /56 to each customer, leaving OP in a terrible position when it comes to proper IPv6 deployment.

When you look at Ziply Fiber, they seem to be ripping out these types of Enterprise grade routers left and right in favor of a simple Linux box doing routing. I think a large portion of why they're doing this is due to limitations like what OP is experiencing

Fabricio202• 3 months ago

Both of which are LPM and cause the issue I just mentioned! It's not about "routing lower than a /64" its about LPM vs Exact Match memory bank usage (and for some reason, how much more expensive good hardware that handles LPM is).

simfree2• 3 months ago

Never mind the actual performance issues that I keep seeing in production deployments.

We have large networks that are essentially rolling on autopilot totally unmanaged, like Lumen'e recently sold Quantum Fiber asset that is now owned by AT&T holding company Forged Fiber 37 LLC

No native IPv6 still on this forgotten about network, 6RD keeps having weird routability issues, but if you just disable IPv6 everything works fine.

imoverclocked4• 3 months ago

NAT requires remembering every connection pair (IPv4:port for both internal and external sides of the NAT)

You don’t need more than the /64 to know where to send traffic, all of the bits required are still just in the prefix. One route per customer… the edge deals with addressing issues.

torginus3• 3 months ago

My personal opinion of having worked with all layers of networking for my job without developing a comprehensive understanding, is this:

We as consumers see and use the highest level, which is often https or friends, and due to the layered nature of the OSI stack, as often happens in software, if a layer is lacking in something, it gets fixed 1 or 2 layers up. If then said thing is then implemented on the layer its supposed to, its often unwelcome and just causes issues.

TCP/IP has already acknowledged this (haha) by offering UDP, on top of which you can build the network protocol of your dreams.

And people have. It's called QUIC or HTTP3. It does everything one could ask of a network protocol, with QoS, NAT punchthrough, packet based low latency/overhead comms, etc. etc.

And QUIC doesn't assume any sort of advanced mechanisms beneath, it works happily with IPv4.

And once you have everything figured out for you on the level you like to work, there's not really a need for the lower layers to pick up the slack, as long as they work reliably.

torginus3• 3 months ago

I wish people actually put some thought into responding as opposed to just hitting the downvote button

yencabulator• 3 months ago

You are being downvoted because nothing you said seems to have anything to do with IPv6. It seems you think as long as it's not your problem, it's solved?

arjie• 3 months ago

I have a /56 at the datacenter and Google Fiber gives me something like a /64 or something so I have full IPv6 connectivity everywhere. For the most part this is fine, but I've noticed the Internet is 'less reliable' on IPv6 and so in my head I still feel like it's a little iffy. There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on. I just think it's the same as my blog's Gemini protocol server. I don't use it and offer it for fun but it's a best-effort basis. If it went down for months I wouldn't notice.

hackeraccount3• 3 months ago

Man a /56 is not as big as you think. I'm an IPv6 neophyte but I'm starting to think about /64's the way I think I think about IPv4 /24's but 802.11 /24's y'know?

So Google Fiber giving a you a /64 is the same as saying - would you run your home network on a single /24. I mean ... you could but it feel like saying could you have one pair of shoes. XFinitity gives me a /60 and honestly I feel unhappy about it.

At my modestly sized job site we're easily using a couple 100 /24's - and I'm not in network operations so that number is probably wrong.

hackeraccount3• 3 months ago

Just for fun and bitterness I checked on Google Fiber.

"Google Fiber generally hands out a /56 IPv6 prefix delegation to residential customers, which allows for 256 subnets of \64's) each."

Totally confused as to why XFinity only gives me a /60. I think it's a benefit for people who get the business class - that is a /56.

miyuru3• 3 months ago

There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on If it went down for months I wouldn't notice.

you are not alone.

I am building a service to monitor such events. usual up-time monitors mostly checks the v4 address.

https://v6monitor.com/tools/ipv6-check

imoverclocked4• 3 months ago

Despite the article title, IPv6 is not the complication. The problem is that IPv4 is incumbent and IPv6 has to live along side of it. It doesn’t matter how it’s done, the dual stack nature of expanding the addressing system will always exist.

tardedmeme28• 3 months ago

this is why people keep inventing nonsense like ipv8 which is worse than ipv6 in every possible way but they think because ipv6 has problems and ipv8 isn't ipv6, ipv8 doesn't have exactly the same problems.

hackeraccount3• 3 months ago

Dual stack isn't a terrible experience it's just usually bad. I wonder if more effort should have been put into making dual stack good instead of making IPv6 good?

Would that have been possible? No clue but my instinct is that most design decisions are trade offs and if you can imagine a trade there's someone out there clever enough to make it happen.

imoverclocked4• 3 months ago

IMHO, the worst thing about dual-stack is that you have to do it at all. There are translation mechanisms but that doesn’t help when you have local devices (maybe IoT?) that don’t support IPv6.

everdrive• 3 months ago

This is the only topic that tempts me to create a throwaway account. (I have not given in) None of the IPv6 proponents are willing to acknowledge that IPv6 is a pain.

All of them seem to have gone to some secret seminar somewhere where they receive their talking points:

- Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.

- There's absolutely no downside whatsoever to being publicly addressable. (also this is a good time to reiterate that NO ONE understands that NAT is not a firewall)

- 128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.

- The entire internet would be hosting home servers if not for the evils of NAT.

PunchyHamster• 3 months ago

You forgot important thing: There will always be some security guy yelling that leaking your internal IP structure is bad.

There will also be another clown that does IP whitelisting as security measure and refuses to just whitelist single /64|/24 network "because it is too wide" (I literally had this conversation last week with one of the clients)

- The entire internet would be hosting home servers if not for the evils of NAT.

ISPs will find a way to fuck up

adrithmetiqa• 3 months ago

It would have been a success if they just called it ipv5.

ahoka• 3 months ago

IPv6 is classic second system effect.

zadikian30• 3 months ago

The downside of publicly-addressable hosts is actually acknowledged in things like RFC 6092, but REC-49 is that routers provide a clear firewalling option that MAY be default-allow.

kstrauser4• 3 months ago

Everyone who dislikes IPv6 doesn't know how NAT works and thinks it's the same as a firewall.

It would be easier if IPvOld proponents didn't keep saying that it is. Seriously, every time this topic comes up, at least one person expresses horror at the idea of running IPv6 without a firewall, unlike their safely NAT-firewalled IPv4 setup.

There's absolutely no downside whatsoever to being publicly addressable.

I won't say there's no downside, because such a thing is possible. It's just that I've never actually heard one outside weirdly contrived scenarios like "but what if they're not using a firewall", which is something you'd have to go out of your way to do.

128 bit addresses are exactly as convenient and memorable as as 32-bit addresses.

It's more realistic to say that IPv4 addresses are less horrid than IPv6, while still horrid. Who are all these people who don't like using DNS?

The entire internet would be hosting home servers if not for the evils of NAT.

Um, true. I was on the Internet before NAT became popular, and P2P connections were the norm, not some weird thing you had to hack up with a STUN broker or such. NAT, more than any other single technology, worked to turn the Internet from a collection of peers to a producer-consumer arrangement. There's no scheme in which having the possibility of P2P connections is worse than only allowing client-server.

zadikian30• 3 months ago

"Who are all these people who don't like using DNS?"

"It's always DNS," and mDNS is finicky too. At least, not reliable enough that I can never look at addresses again.

da_chicken2• 3 months ago

Everyone likes to use DNS.

How do I use DNS on my home network to set up my home router? It's the same problem as TLS certificates on web interfaces for infrastructure.

And the commercial solution is going to be "pay us a subscription fee so your home device can get an Internet management interface on top of all the egregious data collection".

globular-toast2• 3 months ago

This comment would make more sense if you said why IPv6 is a pain. It just works for me.

mixmastamyk3• 3 months ago

Works but addresses are unreadable. Ensuring security on a small network is more difficult than it needs to be when addresses are gibberish. Still not sure mine is on IPv6.

mwwaters• 3 months ago

SLAAC and link-local is very different from DHCP/NAT/etc. in IPv4 world. Link-local addresses are pretty arcane in IPv4 while they are a central idea in IPv6.

That’s fine. As pointed out elsewhere, DHCP was relatively new when IPv6 was introduced. But it is a learning curve well past just knowing the difference between NAT and stateful firewall.

boredatoms• 3 months ago

Everyone forgets you can NAT ipv6 just like you would v4

zadikian30• 3 months ago

You can, but the recommendation is no NAT with v6. Most routers don't even support it.

ghusto• 3 months ago

In troubleshooting, "It's always DNS" has become "If it's not DNS, it's IPv6".

I don't even try to fix it. If I disable IPv6 and everything starts working, I move on.

tardedmeme28• 3 months ago

On my network, if it's not DNS, it's IPv4. IPv6 just works. I wish websites would hurry up and get with the times so I could turn off this old pile of hacks already.

pseudohadamard• 3 months ago

Their NAT-phobia was legendary, and it carried through to other WGs as well like IPsec. The fact that IPsec broke NAT was a feature because it would force everyone to move to IPv6 ,for example.

The crazy was strong in those ones.

AshamedCaptain• 3 months ago

But NAT is _not_ a firewall. It's entire purpose is to allow traffic through. There's a million dozen tricks attackers can play, e.g. tricking a PC into sending traffic to some address will usually allow all traffic from that address back into one's precious network.

This is a common misconception and very dangerous -- I see a lot of people, ISPs even, who seem to think NAT is enough and you only need the firewall for IPv6.

bborud3• 3 months ago

Why are we, in 2026, still talking about ipv6? It is time to give it up and start over. Yes, it is unlikely we can agree on an ipv4 successor. But at this point we should be able to agree ipv6 is not going to be it.

msla• 3 months ago

For the same reason we, in 2026, are still talking about Java.

zadikian30• 3 months ago

Java bent a lot to accommodate. There are lambdas and records which violate the old OOP rules, and now virtual threads which were sorely missing for things like web backends.

tardedmeme28• 3 months ago

What do you think should be done instead? If ipv4 but with longer addresses (which is called ipv6) is not to your satisfaction, what would be? You want to completely overhaul the internet like in ipv8 and you think ipv8 doesn't have the exact same problems and thousands more just because it's never been deployed and nobody's encountered them yet?

bborud3• 3 months ago

You appear to not understand my argument.

IPv6 is over 30 years old. The world has not embraced it. It isn’t going to. It is time to call it and try to figure out something that will work.

You do understand that one need not have a better idea to make that observation? The observation is self-evident and can exist in the world regardless of what we think about IPv6 or the feasibility of figuring out something people will want to use.

Getting defensive and playing “then you come up with something better”-games is not getting us anywhere. It is just part of the problem. It is unproductive.

30 years. Let’s not waste more time.

AndrewDucker2• 3 months ago

IPv6 is over 50% of Google requests. It's made it. It's the future.

https://www.google.com/intl/en/ipv6/statistics.html

gred• 3 months ago

They should have had the UTF-8 guys tackle IPv6. Talk about elegant.

mixmastamyk3• 3 months ago

Great idea, somewhat similar to what I mentioned at: https://news.ycombinator.com/item?id=47991652

t435625• 3 months ago

IPv6 is awesome and I'm so happy that my local network is IPv6 and my provider offers IPv6 by default too.

I think it offers hope that we can serve up data in a much more peer-to-peer way without going via "bigcorp" servers.

To break the network as a security measure seems the absolute wrong fix to me and it's hard to understand the logic of it.

Why IPv6 is so complicated

Related Stories