Live data from Hacker News

Why IPv6 is so complicated

github.com

81–90 of 519 posts

Re: Why IPv6 is so complicated

#81
post #21
post #15

Earlier quoted context omitted.

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.

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

What protection? What privacy? Smoke and mirrors, mostly.

NAT is a firewall with extra steps. IPv6 reduces complexity. Privacy (illusion of it, anyway, just like in ipv4 NAT) is handled by private addresses.

…and if you really want to, NAT for ipv6 just works.

Re: Why IPv6 is so complicated

#82
post #71

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

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

> 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

Re: Why IPv6 is so complicated

#83
post #56
post #44

Earlier quoted context omitted.

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?

DHCP requires explicit configuration; it needs a range that hopefully doesn't conflict with any VPN you use; it needs changes if your range ever gets too small; and it's just another moving part really. With SLAAC, it's just another implementation detail of the protocol that you usually don't have to even think about, because it just works. That is a clear benefit to me.

When it fail, you find there is no option to tune its behaviour.

Plug in a rough router and see quickly you can find it.

Re: Why IPv6 is so complicated

#84
post #77
post #68

Earlier quoted context omitted.

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…

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…

Nah, you didn't fix anything, you just moved the problem around.

(Worst case, you moved the problem to your finance department, for buying IPv4 address space. But even if you didn't do that, at some point sooner or later you'll get pressure to support IPv6. And then you'll have to "un-fix" everything you did, and fix the actual problem. Maybe it'll be after you're retire, but I wouldn't take bets on that.)

[ed.: best case, you moved the problem to someone else outside your company or scope. Good for you, I guess. Like the sibling post says, address space shortage is an issue for everyone, and personally speaking I would consider it rude to make it other people's problem.]

Re: Why IPv6 is so complicated

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

Re: Why IPv6 is so complicated

#86
post #34
post #26

Earlier quoted context omitted.

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

There are no more acronyms. SLAAC means automatic client configuration. That's the only one you need. > give up control of your home network. What does that even mean? What do you gain by deciding your Apple TV should be at 192.168.0.3? With IPv6, you can just `ping appletv` and it works fine. What more "control" do you need?

> you can just `ping appletv` and it works fine.

How many service does it take to make this work?

mDNS is quite fragile.

Re: Why IPv6 is so complicated

#87
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

Re: Why IPv6 is so complicated

#88
post #76
post #67

Earlier quoted context omitted.

> I mean generally I want fixed IPs on my local network for robustness. What do you mean by robustness? Isn't it really stable hostnames that you want? I don't understand how fixed IPs increase resilience (to what?). > I'm hesitant to turn it on on my local network because it does make my firewalling concerns much more critical. Block everything coming in from outside the network. Allow established connections. That'…

You're assuming there is only one internet connection in my home network, for example. The "easy" trick where your ISP gives you routable addresses does not work when there's more than one exit. Still want to help? :) And really... everyone is pushing for SSL everywhere - among other things so that the ISP doesn't MITM your traffic. Why would you allow the ISP to know what machines are inside your home network then?

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 really assume that corresponds to the number of physical devices in your network?

Re: Why IPv6 is so complicated

#89
post #77
post #68

Earlier quoted context omitted.

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…

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 difficult to fix than having to properly configure your server.

Re: Why IPv6 is so complicated

#90
post #10

Earlier quoted context omitted.

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

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…

Dual-stack was the only coexistence option for a long time, until NAT64 came around. There were a whole bunch of attempts at compatibility, e.g. with "::1.1.1.1" and "::ffff:1.1.1.1" as IPv6 addresses, they just didn't go anywhere. (Well, not quite, the latter is in POSIX and in socket libraries around the planet. Doesn't leave the host though. At least it's not supposed to. I have some horror stories…)

NAT64 started happening because it solves real problems — large eyeball networks, particularly mobile phone networks, didn't want to pay for twice as large table sizes on their routers and twice the maintenance effort. So they made IPv6 end hosts capable of connecting to IPv4 systems. But this is 2010 era, IPv6 was ≈15 years old at that point!

Post reply on HN