Live data from Hacker News

Why IPv6 is so complicated

github.com

101–110 of 519 posts

Re: Why IPv6 is so complicated

#101
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.

Re: Why IPv6 is so complicated

#102
post #77

Earlier quoted context omitted.

I fixed the problem once for all. Now my program even refuses to start, if IPv6 is enabled. I am not going to spend time debugging problem, that can be easily prevented. Pretty valid solution on private networks and local only kubernetes deployments. If customer wants proper ipv6 support, we can sign a contract and talk about it. But do not expect me to support some technology for free, just because it is enabled by…

This attitude is widespread enough to hold the world back by forcing everyone who interacts with the public Internet to support ipv4 (some technology), "for free". So, either way, we're forcing one of them. So, we might as well lean towards supporting the one that isn't hard capped at 4 billion addresses in a world with at least 2x as many devices. Have you ever tried to deal with NAT punchthrough? That's way more di…

> Have you ever tried to deal with NAT punchthrough? That's way more difficult to fix than having to properly configure your server.

Yes I did, and I no longer support that either. For my setups it is local private ipv4 networks all the way now! How tailscale or other VPN deals with that is not my problem!

If two nodes are on different networks, they should not be allowed to talk to each other anyway. Seems like security risk! Clean design, simple rules!

Re: Why IPv6 is so complicated

#103

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

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.

Re: Why IPv6 is so complicated

#104
post #98
post #88

Earlier quoted context omitted.

This doesn’t change anything about the NAT or firewall story, and having two different connections is complex with IPv4 just as well. Aside from being a fairly exotic setup for personal use anyway. What would your ISP do with the information that there are 73 unique addresses in your network at this point in time? Especially given that devices may mint any number of them for different reasons, so you can’t even reall…

> Aside from being a fairly exotic setup for personal use anyway. So I should cancel one of my pipes because the "commitee" overcomplicated things in the name of autoconfiguration? > What would your ISP do with the information that there are 73 unique addresses in your network at this point in time? Sell it of course. Good info for targeting marketing/political propaganda per household. > I haven’t seen a bog-standar…

> So I should cancel one of my pipes because the "commitee" overcomplicated things in the name of autoconfiguration?

That is absolutely not what I said. It’s a more complex setup than a single connection with either protocol, and can be solved with both.

> Which one, the one from ISP A or the one from ISP B? :)

Realistically it is going to return an A record with both addresses, maybe also the link-local one, any works locally. That is a non-issue.

Re: Why IPv6 is so complicated

#105

Earlier quoted context omitted.

> 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…

But would we have said the same in 1996 or 2000? Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4. And a good chunk of the complexity of IPv6 is that some of the early ideas are very persistent, both in some deployed systems and in people's minds

> But would we have said the same in we 1996 or 2000?

IPv6 the protocol supported NAT just as well back then as it does now, but the software probably didn't. Which goes back to my point [0] [1] that IPv6 is a great protocol with bad tooling and documentation.

> Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4.

The only abandoned IPv6 concept that I'm personally aware of is A6 records [2], but I'm pretty young, so I'm sure that there are others that I'm just not aware of. My impression from reading the RFCs and Wikipedia is that IPv6 hasn't changed very much, but that doesn't really mean anything, since I wouldn't expect for current sources to talk about concepts abandoned 20+ years ago.

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

[1]: https://news.ycombinator.com/item?id=44773999

[2]: https://datatracker.ietf.org/doc/html/rfc6563

Re: Why IPv6 is so complicated

#106
post #52
post #31

Earlier quoted context omitted.

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

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.

Just as much as people are not entitled to lack of change, they are not obligated to enjoy, welcome or facilitate change.

What I learned about IPv4 at the turn of the century allows me to comfortably plan and manage networks up to a few thousand nodes, maybe a few tens of thousands.

I don't work in networking anymore. I really don't care about what those who are in that business. What you need to manage contemporary billion-node size networks and interchange between them is not my problem. You try to make it my problem, but I don't care.

I'll continue organizing the very few and very small networks that are still my responsibility using pre-CIDR ideas.

Maybe it becomes impossible some day. I'll deal with it then.

Re: Why IPv6 is so complicated

#107
post #5

> 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 proble…

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

Re: Why IPv6 is so complicated

#108
post #70
post #53

Earlier quoted context omitted.

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 tr…

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...

For exactly the reasons I stated

Re: Why IPv6 is so complicated

#109

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:…

>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.

Re: Why IPv6 is so complicated

#110
post #63
post #53

Earlier quoted context omitted.

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 tr…

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…

> and that's fairly easy to reason about for me

But we aren’t talking about someone technical glancing at their home routers firewall. We are talking about explaining a network topology to enterprise teams like change management, CISO, etc in large infrastructure environments.

That’s a whole different problem and half the time the people signing off that change either aren’t familiar with the infrastructure (which means explaining the entire context from the ground up) and often aren’t even engineers so need those changes explained in a simplified yet still retaining the technical detail.

These types of organisations mandate CIS / NIST / etc compliance even where it makes zero sense and getting action items in such reports marked as “not required” often takes a meeting in itself with deep architectural discussing with semi-technical people.

Are these types of organisations overly bureaucratic? Absolutely. But that’s typical for any enterprise organisation where processes have been placed to protect individuals and the business from undue risk.

In short, what works for home set ups or even a start up isn’t necessarily what’s going to work for enterprise.

Post reply on HN