Live data from Hacker News

Why IPv6 is so complicated

github.com

241–250 of 519 posts

Re: Why IPv6 is so complicated

#241

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…

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

Re: Why IPv6 is so complicated

#242

Earlier quoted context omitted.

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

If you’re dual stack, your OS will prefer IPv4 to ULA and ULA won’t be used at all, and so the extra config overhead of deploying ULA is pointless.

It'll prefer ULAs when connecting to hosts without A records. Programs will use ULAs if you connect to an IP literal, or if connecting to the A records fails. Also, Linux/glibc will prefer ULAs if you have a ULA assigned to the machine, and so will anything using the update to RFC 6724. So "ULA won't be used at all" is definitely not correct.

Re: Why IPv6 is so complicated

#243
post #232

Earlier quoted context omitted.

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

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…

> The original comment also doesn't state they are issues just that they are differences.

My point is that, in most cases, these aren’t differences, since IPv4 does the same thing as IPv6. Therefore, the claim that IPv6 “has some quirks that make it harder to digest [than IPv4]” is incorrect.

> Interfaces do not have link local addresses if they have a DHCP or statically configured address

I could be wrong, but I seem to recall that Windows machines always have a IPv4LL address?

> in V6 it is extremely common to use a link local address as the gateway

What? I have never seen this.

Re: Why IPv6 is so complicated

#244

Earlier quoted context omitted.

Can you just NAT66?

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.

You can change the priority.

Re: Why IPv6 is so complicated

#245
post #167

Earlier quoted context omitted.

Please consider that maybe the people working on v6 weren't actually complete imbeciles and did in fact think things through. It is possible for the world to change, and for designs and plans and viewpoints 30+ years ago to be less correct today. This world is not that world. That world had massive concerns about the processing cost of NAT. That was one reason for ipv6. It also had different ideas about where the net…

None of that has anything to do with what you said in the post I replied to. "Add an extra octet to v4 addresses" has hard technical barriers to deal with if you want it to work, regardless of what the world looks like or what you're designing for. > We now know that the "internet of things" and "having your fridge online", as well as "5G in everything so people can't firewall it off" is just insane and malign None o…

None of that has anything to do with what you said in the post I replied to.

Of course not, why would it? I quoted what I was replying to, and all of my comments made perfect sense in that context. In that context, I was discussing the winning ipv6's original design considerations, and yes "IPs for everything" was one of them, hence me talking about it.

Re: Why IPv6 is so complicated

#246
post #207
post #62

Earlier quoted context omitted.

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…

Pretty much the only way I've seen a /48 split in practice is to get 256 /56 (one per site) then 256 /64 (one per VLAN).

/52 and /60 are quite common as well, predictably what with falling on a "letter boundary" and all

Re: Why IPv6 is so complicated

#247

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

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

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.

Re: Why IPv6 is so complicated

#249
post #207

Earlier quoted context omitted.

Pretty much the only way I've seen a /48 split in practice is to get 256 /56 (one per site) then 256 /64 (one per VLAN).

/52 and /60 are quite common as well, predictably what with falling on a "letter boundary" and all

Interesting. I've only seen /60 when they're trying to split up a /56, and IMO it's a little unclean.

Re: Why IPv6 is so complicated

#250
post #168

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.

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