Hacker News Reader

I think that it's fair to blame the specification. I don't think the problem is that the industry has changed, I think it's that there's a huge amount of friction and headache for shifting to it. I think that's because it was too large of a change all at once, combined with the initial specification having some real problems (that did eventually get mitigated in later specs).

I suspect that if IPv6 limited itself to just increasing the size of IP addresses, IPv4 would largely be a distant memory by now.

"IPv4 with bigger addresses" would never have been backwards compatible and would always have been a compatibility break and would always have a slow rollout.

The proposals that seemed backwards compatible were just aggressive CGNAT consolidating even more power in the hands of IPv4 address owners. That doesn't seem like a sustainable fix in the long run.

> "IPv4 with bigger addresses" would never have been backwards compatible and would always have been a compatibility break

True, but it would limit that break to a single thing. That's much easier to deal with than the whole basket of things that IPv6 brings with it.

Compatibility breaks are always headaches. There's not "just broke a 'single' thing" when it comes to compatibility breaks. That is why strict semver suggests a major bump no matter how "small" a compatibility break appears to the developer. There is no such thing as a "simple" compatibility break to downstream users.

In general, despite the complex vocabulary about most of it, in many ways IPv6 is simpler than IPv4. Its header has fewer fields. Its QoL/QoS fields aren't accidental hacks on top of old debugging fields but intentionally designed fields for that very purpose. SLAAC is a simpler protocol than DHCPv4, though the algorithm sounds more complex at first. (DHCPv6 is basically as complex, but fewer devices and fewer subnets should need DHCPv6 in the first place.) Much of the "basket of things" that IPv6 brings with it are designed to remove complexity that has concreted around IPv4.

They ripped the bandaid completely off with the backwards compatibility break that they made with IPv6, and apparently a lot of people loved the cute stickers they had applied on top of the bandaid. But at this point it is probably better for the skin below to heal without the bandaid than to continue to sticker and bandaid over that and let all that unnecessary glue fester in place. (To push such a metaphor almost to its breaking place.)

> in many ways IPv6 is simpler than IPv4.

It's not really about whether or not IPv6 is simpler than IPv4, though. It's about how painful moving from IPv4 to IPv6 is. And it's very painful. If the only thing that changed between the two was that the IP address space is bigger, it would reduce the pain of changing.

I'm certainly not going to claim that my experience is representative of anyone except for me, but the reason that I'm not going to shift to IPv6 until I literally have no other choice is because doing so is an enormous undertaking. Since IPv6 doesn't bring me any benefit that I care about, there is no reason to do so unless I simply can't get on the internet without it anymore.

Please note: I am not bashing IPv6 here, and I'm not saying that a change isn't needed. I'm just expressing some of the reasons I've seen why people resist changing to it, and that I think adopting it would have happened within a reasonable timeframe if it weren't as ambitious.

> I think adopting it would have happened within a reasonable timeframe if it weren't as ambitious.

There's zero proof that an "extended IPv4" would have been adopted on a "more reasonable" timeframe, no matter how you define "reasonable" (faster, I guess is what you are arguing for?).

Exactly where and how do you expect "just add more address bits to IPv4" is an easier transition than IPv6?

The IPv4 header is a fixed size. You can't add more address bits without breaking existing routers. Period. End of technical story. You could embed the additional address bits in the next layer up (TCP/UDP) but you greatly increase the complexity of routing equipment by making it have to understand those layers, to what benefit? In the dual-stack real world we do that all the time with VPNs and STUN tunnels and other gateways and tunnels. We have those exact same tools, already, and those haven't made the transition any more "reasonable", have they?

But it's worse that while routers don't understand the extra bits, the parts of the addresses that get used (the prefixes small enough to fit in IPv4 headers) have to become massive NAT gateways and become massive gatekeepers of huge parts of the IP address space. We know from deep experience that IPv4 address allocation wasn't "equitable" (ARIN got way more space than RIPE and both got more space than AFRINIC and so on; companies like Microsoft and GE got /8 allocations just for asking in the right years).

Does it make that much sense to establish existing IPv4 holders as the forever "landlords" of the internet? That seems to me to only add more incentives to make the transition more unreasonable than IPv6: why support router initiatives that understand the additional address space when the IPv4 address holders can get "extra rent" if they don't, presumably charging all their "downstream" traffic for their gateway usage? We're in a time where IPv4 addresses have noticeable rental costs, I can't imagine what that would be like in a world where large parts of address space have to be on VPNs controlled by IPv4 owners. That doesn't sound to me like a good present or future for the IP protocol, no matter what.

It's honestly not that hard. Looking at your other posts, you think it's hard because you're unfamiliar with it, because you're trying to overcomplicate it, and because you're trying to do everything all at once rather than gradually.

None of these things are IPv6's fault.

Hell, give me remote access to your network and I'll set it up for you -- at least enough to get you started on it if not 100% on every single thing. I don't expect you'll take me up on that offer, but it'd be easier to just do it than tell you about it, since you can't tell people anything: http://habitatchronicles.com/2004/04/you-cant-tell-people-an...

Why is it so painful for you? As someone that has been running everything dualstack for over a decade I'm seriously interested where people are struggling with it.

The only pain I've ever seen is in corporate networks where all the tooling around the network management are IPv4 only but those would break even if you add a single bit to an IPv4 address.

ISP doesn't provide much in terms of support. They had a IPv6 page for some years announcing it was available for the eager ones, which has been since been taken down. Searching for IPv6 in their documentation comes up empty.

Software isn't ready or was written back in the early days before they figured out how IPv6 would actually be deployed. I had an Asus router back in the days, it had primitive and unstable IPv6 support, which just grabbed a single /64 and that was it.

I then ran pfSense for some years and it was unusable for IPv6 due to everything being geared around fixed prefix. Even if my ISP had given me a fixed prefix it would have been a pain, because I got two new cable modems in that period (one due to the previous being too old, other one due to a move), so would have gotten a new prefixes anyway and would have had to rewrite all my firewall rules. Would have been major PITA each time. No such need with IPv4.

I switched to OpenWRT some years ago and it's mostly worked since. Mostly.

Android phones in the homes don't respect my DHCPv6 settings, and it took me some time to figure out it ignored my DNS settings because I had only IPv4 configured as my local DNS server. Other boxes were fine with that, but not Android, which silently used Googles DNS instead.

Running dual stack isn't ideal either, since it can lead to inconsistencies. When some things work and some things don't, and it can be difficult to figure out why because of the non-trivial interaction between IPv4 and IPv6.

It's also painful because just about everything is different. So very little of what I know of how to configure my IPv4 network carries over. It's very much not just IPv4 with more bits. I'm old enough now that I'm not terribly excited about digging around in the IPv6 technical weeds, and I haven't found a good guide or reference I can fall back on.

> Why is it so painful for you?

Mostly because of the number of machines that I have to fix up and the fact that updating each of them involves a fair bit of time. My estimation is I'm looking at at least a week's worth of work, during which my network isn't fully functioning.

It's also complicated by the number of devices I have that aren't possible to make work with IPv6 at all, which means I have to maintain some IPv4 segment and deal with making the two work together in a seamless way.

I'm also very concerned about security. I'm not confident that I know enough about how to secure an IPv6 network adequately, so I need to set aside a fair bit of time for study before I even start.

All in all, it's a large project with a lot of friction that wouldn't be as large if I didn't have to rethink everything.

Going IPv6 only is a pain for sure but why not do dual stack and upgrade one by one and get comfortable with it first?

I could, sure, although if I'm going to do that, I may as well just put an IPv6 translation layer at my router level and keep everything internally at IPv4. Which I'm seriously considering doing as the path of least resistance, particularly since there are no special IPv6 features that I really want or need.

But the last time I mentioned half-measures here on HN, I got dumped on pretty harshly.

I don't think that exists and I can't imagine how a IPv6 translation layer with internally IPv4 addresses should work. What exactly do you want to do?

Some NAT46 (not to be confused with NAT64) tools and routers exist in the wild today. "Stateless" ones work by manually setting routes for chosen IPv4 addresses to IPv6 ones or treating all of IPv4 traffic as the "ultimate" semi-private IPv6 "subnet" and prepend a fixed IPv6 prefix to all IPv4 traffic (and you can do that with just about any IPv6 /64). Stateful ones act a lot like NAT44 routers and can also use "out-of-bound" protocols similar to NAT44's UPnP (but I think distinct from?) to setup routes on the fly from application requests.

Though they exist, my understanding is that the need and use cases for them is overall much weaker than NAT64 or NAT44.

If the internet destinations I want to reach have an IPv4 address, it's obviously very easy. It's just a kind of NAT. And everywhere I want to reach has IPv4 addresses and probably will for a long time.

If they're IPv6 and I really need to reach them anyway, then I could imagine writing a special NAT that keeps a database equating IPv4 addresses (that I make up) with real IPv6 addresses on the net and doing a NAT that way. That would be suboptimal because it would mean that I'd need to add a database entry in advance for each internet destination, of course. But it seems feasible. And I can think of a couple of ways to automate it.

But, honestly, I don't know. I'm just spitballing what the best way of handling all of this actually is. Every method I have heard or can think of has some serious downside, and I don't have sufficient expertise (and haven't spent the time) to do actual cost/benefit analyses of the various options yet.

This is all a huge time-consuming hassle, and is why I'm putting the whole thing off until I have no other option.

> The problem is that the computing industry has changed.

Nah, the problem is ipv6 has been designed by a commitee for a lot of enterprise-ish features so the hobbyists have taken a look and postponed setting it up internally for when they have absolutely no choice.

I've asked for simple ipv6 tutorials in discussions on HN and elsewhere and whatever I got pointed at was always longer than the article we're discussing and incomplete.

Basic set up of ipv4 for a home network can be explained over just one pint. Looks like you need two barrells for ipv6.

- https://openwrt.org/docs/guide-user/network/ipv6/configurati...

- https://openwrt.org/docs/guide-user/network/routing/examples...

- https://openwrt.org/docs/guide-user/network/ipv6_ipv4_transi...

- https://openwrt.org/docs/guide-user/network/ipv6/ipv6_extras

Yeah right. The summary of the first page already throws around like 4-5 acronyms that each require reading a separate documentation.

And that's only for configuring your router, not your local network...

Okay then please provide me the level of documentation you are looking for, but for an IPv4 network. Sounds wonderful, I'd love to share it with new hires.

> I've asked for simple ipv6 tutorials

There really does seem to be a lack of good documentation about all of this. The docs that I've seen appear to be aimed at actual network engineers, or are so incomplete as to not be worthwhile.

I would be much less stressed by all of this if I could find something good that sits between those two extremes.

A part of me, though, suspects that the reason there is no "middle ground" documentation is that it's not possible -- that IPv6 is too complex for that. Not saying that's the actual reality, but it has the whiff of it.

All networking is complex.

I asked the other guy this, but I'll also ask you. Please provide me the level of documentation you are looking for, but for an IPv4 network. If you have some grand tutorial that explains it as easily as you make it out to be, then I truly would love to see it, I will include it in my onboarding documentation at work.

Because I understand both IPv4 and IPv6, and do not consider IPv6 the more complex protocol by any measure. I suspect your "whiff" is more a bias towards what you are comfortable with, rather than a true reflection of IPv6's complexity.

> Because I understand both IPv4 and IPv6, and do not consider IPv6 the more complex protocol by any measure.

You mentioned "new hires" while i mentioned hobbyists. You're talking about a business network where people are paid to do it, I'm talking about home networks and home labs.

You're basically confirming my statement that IPv6 was designed for enterprise needs?

There are millions of people using IPv6 without knowing it. The ISP has everything preconfigured and if you use a third party router it's normaly one or two options to set. And it just works like for IPv4.

I have that. Not enough at hobbyist level though.

>Please provide me the level of documentation you are looking for, but for an IPv4 network.

Could help to get an idea what you see as "hobbyist level". Setting up IPv6 has been pretty straight forward on plain Ubuntu as a router just with replacing the dhcpd subnet configs with a radvd config, enable ipv6 forwarding in addition to ipv4 forwarding and replace the iptables NAT rule with a only forward RELATED,ESTABLISHED connections (which already is optional).

Two fiber connections coming inside my home. One is a home connection with a router that sends ipv6 to any machine that asks for it (which i may not always want), the other one is a business connection that goes into an Ubuntu router that has to run pppoe.

The path of least resistance with ipv4 was to have static ips for every PC and change the default route where I cared about which connection the PC used. Also was using the dhcp from the home router.

Now ipv6 has addresses that are auto generated by the OS on boot, addresses that are forwarded from the router and are in a subnet assigned to home ISP #1, and ... whatever I'd need to assign manually?

It's still hobbyist level not enterprise level if you ask me. But it's a lot to read for a network that works just fine thank you.

This auto configuration mechanism is called stateless address autoconfiguration (SLAAC) so "Your OS disable IPv6 SLAAC" or something like that in your favorite search engine should give you the answer. After that you should be able to manually configure your address and gateway like you would for v4. If your prefix is dynamic it gets a bit ugly then you have to use link local addresses and something like NPTv6 or NAT66 on the gateway. A better alternative IMHO would be to use different VLANs for the two networks but then your switch and possibly access point have to support it.

> If your prefix is dynamic it gets a bit ugly then you have to use link local addresses and something like NPTv6 or NAT66 on the gateway.

The home connection is probably dynamic. I asked them about paying extra for a fixed IP and they said they're all out. They meant IPv4 of course but that doesn't mean i get fixed IPv6 now.

> A better alternative IMHO would be to use different VLANs for the two networks but then your switch and possibly access point have to support it.

... and it might be fun getting the internal machines to talk to each other? I ssh around all the time.

> The industry is now even legally making money on many things that would've been considered outright malware just a decade ago.

Sounds a bit over the top. Can you name some examples?

10 years ago if you made software that uses all kinds of lies and dark patterns to get access to a user's contacts list, uploads it to your server and then you did data mining on it, people would be concerned and consider the software malicious.

Likewise with analytics - tracking every single action you do in an app (along with generic metadata such as IP addresses - which often leaks your general location and your relationship with anyone on the same network since you'd be sharing the IP address with them) would have been considered spyware.

When there were talks of tracking people for ad targeting in the early days of the internet people (rightfully) freaked out, even though that tracking was really primitive by today's standards.

All of those things are now considered legitimate and are routinely done.

I remember how often DoubleClick were the villains of tracking and privacy over-reach on early Slashdot, and then Google bought DoubleClick and became worse than DoubleClick ever were as top Slashdot villains and yet Google is still often called the heroes in the adtech space. (Though that sea is somewhat changing again as even more mainstream media catches up to tracking prevention.) It remains such a profound reversal to me.

We also used to have a name for malware that injected ads into your computer: adware. Now ads are just part of Windows.

Indeed. When I look at how far things have fallen in this regard, it gets very hard to feel positive or optimistic about the internet.

And the human race. The biggest revolution in communication since Gutenberg, and in less than half a century it's been used almost exclusively for evil purposes.

Instagram, for one.