Live data from Hacker News

Why IPv6 is so complicated

github.com

491–500 of 519 posts

Re: Why IPv6 is so complicated

#491

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…

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.

Re: Why IPv6 is so complicated

#492

Earlier quoted context omitted.

There are lots of services I can't send v6 to, not because some router in the middle only understands v4 but because the service operator decided not to deal with v6.

So the idea is to surreptitiously install software on the service operator's machines that they can't disable? It's already a bit like that, but they can and do disable it. You can see the other comments in this thread: many people disable IPv6 upon any sign of a networking problem.

No, the idea is you can turn v6 on/off, but doing so only changes the packet format and nothing else at first. There's no separate place to configure v6-specific settings because there are none. You use the same address, routes, DHCP, NAT, DNS, etc as v4, but you're limited to 32-bit addrs at first. The point is to just get people off v4.

Once v6 has reached enough adoption, you can turn off v4. Those who want to keep the addrs from v4 can, except now they get way more addresses under those too. Others can start building a clean new topology under the other prefixes without worrying about compatibility.

Re: Why IPv6 is so complicated

#493

Earlier quoted context omitted.

It requires the router to support v6. If you want, could do an approach kinda like "happy eyeballs" where you try both.

If the whole path supports ipv6 what is the purpose of the compatibility trick?

If you want to start using v6 before you're sure that every host supports it. But this isn't strictly needed, could just rely on something in DNS telling you the host supports it (I'm not saying AAAA records cause idk if you'd use them in this scheme).

Re: Why IPv6 is so complicated

#494

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

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

Re: Why IPv6 is so complicated

#495
post #382

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.

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

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

Re: Why IPv6 is so complicated

#496

Earlier quoted context omitted.

So the idea is to surreptitiously install software on the service operator's machines that they can't disable? It's already a bit like that, but they can and do disable it. You can see the other comments in this thread: many people disable IPv6 upon any sign of a networking problem.

No, the idea is you can turn v6 on/off, but doing so only changes the packet format and nothing else at first. There's no separate place to configure v6-specific settings because there are none. You use the same address, routes, DHCP, NAT, DNS, etc as v4, but you're limited to 32-bit addrs at first. The point is to just get people off v4. Once v6 has reached enough adoption, you can turn off v4. Those who want to kee…

I don't see why anyone would change all the bits you actually need to change for some nebulous future gains. Still have to deal with new sockets and new routing decisions at least. To not really gain much from new features.

To me it looks like something that would have gained nearly no actual adoption outside some toy examples. Later you will need to anyway get new DNS, DHCP(or alternative) and so on.

Re: Why IPv6 is so complicated

#497

Earlier quoted context omitted.

I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Neither NAT64 or NAT46 do this really, and they're presented as alternatives rather than the native way. The closest was 6to4. rfc6343 goes into why that got deprecated. You'd either have "router 6to4" which required additional se…

> I want something:x.x.x.x to get routed to me over v6 if I had x.x.x.x in v4, as the default and recommended way of contacting an ipv6 host, without needing additional config or middleboxes. Anyone with an IPv4 automatically got a 'free' IPv6 allocation: > For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network be…

Owning 192.0.2.4 in v4 didn't really give you 2002:192.0.2.4 in v6, as in v6 packets can't reach you that way. If someone sent a v6 packet there, some router on their side would intercept it and relay as v4. Aside from this still relying on v4, it was very unreliable in practice because of uncertainty around what v6 route is taken to the relay. There's an RFC somewhere that looked at this in hindsight.

Re: Why IPv6 is so complicated

#498

Earlier quoted context omitted.

Yeah we're talking about the same thing. So my v4 is 70.94.201.31. My ISP didn't also give me 2002:70.94.201.31 or whatever.

> My ISP didn't also give me 2002:70.94.201.31 or whatever. Traffic to 2002:70.94.201.31/48 is tunnelled via 70.94.201.31 with-in an IPv4 packet (encapsulation): * https://en.wikipedia.org/wiki/6to4

I mentioned 6to4 in the original comment. It doesn't fulfill this use case, it still relies on v4 packets.

Re: Why IPv6 is so complicated

#499
post #482

Earlier quoted context omitted.

So now please get to step 2 of the argument: why do you think a world that did not embrace IPv6 (a false premise by the way, as 50% of internet traffic is IPv6) would embrace IPvBBORUD?

Again, you are not getting the argument. IPv6 is dead. It is better go give up and see what else can be done. Stop and think about what I'm saying before you react. Are you suggesting we spend another 30 years beating a dead horse?

If you call 50% of internet traffic "dead" then I guess IPv4 is dead too.

Again, you have refused to answer what would make IPvBBORUD better?

Re: Why IPv6 is so complicated

#500

Earlier quoted context omitted.

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.

Can you give examples of when you need to know IPv4 addresses for security reasons?

When I write firewall rules I write the address into them. There’s multiple address6s per host and complex enough I give up.
Post reply on HN