Live data from Hacker News

IPv6 is the only way forward

ankshilp.in

51–60 of 350 posts

Re: IPv6 is the only way forward

#51
post #38
post #23

Earlier quoted context omitted.

Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an IPv4 + an hex suffix, maybe at the expense of not having a humongous address space. So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version. I just made th…

How do you squeeze that in IPv4 packet? Especially in a way that won't get mangled by random ossified devices in between?

In IPv4 you only need to transmit IPv4 addresses. If the "cannot be" in parent post is referring to the exact byte disposition in packets, then I go the other way around to claim that I agree. Because the only way that a UTF8 character can pretend to be ASCII is because ASCII didn't use all of the 8 bits in a byte to begin with. Only way to have something similar in this case, would be that IPv4 didn't use all of the allocated bits for addresses... Which is not the case.

What I argued was that IPv4 could be embedded into IPv6 address space if they had designed for it. But I agree, that the actual packet header layouts would need to look at least a bit different.

Re: IPv6 is the only way forward

#52

Earlier quoted context omitted.

That's because the Internet is basically broadcast TV 2.0 so no one cares about having public IPv4's at home as long as they can get to their memes and streaming. Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries and turned it 21st century brainrot troughs. Perhaps a society not in slow intellectual decline would ha…

> Great job, we took something that was meant to be a next frontier in humanity and let anyone connect with anyone else without gatekeepers/intermediaries We already had that, it's called shortwave radio. The internet, especially as it's implemented and as it's used, is a terrible way to achieve this. It's service providers the whole way down.

There are definitely problems, but IRC in the 90s had strong ham radio vibes imo.

Re: IPv6 is the only way forward

#53
post #19
post #15

Someone should’ve thought about the UX of IPv6 before declaring it to be “the way”. It’s like having to learn Klingon just to setup your printer. IPvNext could sort that out… maybe it’s time to consider moving on.

People claim this all the time, but every time I push I discover they have no clue how networks work and just handwave away as "easy" or "details" the very reasons people who understand networks say it can't work.

>every time I push I discover they have no clue how networks work

Listen here, if there is a networking technology or feature that I wasn't forced learn when I half-assed a SOHO router config in 2005, then it shouldn't exist at all.

Re: IPv6 is the only way forward

#54

IPv6 feels like we just can't admit to ourselves that it has been a failed transition. What would it take to come up with IPv7 which takes in the lessons of IPv6 and produces something better that we can all agree is worth transitioning to over IPv4.

What changes to IPv6 would you make to make it easier to transition?

Re: IPv6 is the only way forward

#55
post #21
post #10

Earlier quoted context omitted.

“They’re out of IPs so they should self-genocide” is certainly something akin to an opinion, but not one I expected to see on this site today.

You're putting words in my mouth, genocide implies murdering existing people to reduce the population, not developing policies that would slow down the population growth and/or fix the issues with the country.

It's not me, it's the UN: Article II, 4.

https://www.un.org/en/genocide-prevention/definition

Re: IPv6 is the only way forward

#56
I find it fascinating how these key technologies handle upgrades and breaking changes. For example, Python eschewed breaking changes through 2.7.x but the dam has burst since 3.0 and every point release (it seems?) makes breaking changes, sometimes reversing itself (eg the whole s/u string prefix thing).

Many here will be familiar with the second system effect [1]. Usually people want to avoid making breaking changes but once they do, they can go a little nuts. My personal opinion is only major versions should make breaking changes and a lot of thought should go into making them as painless as possible.

IPv6 is fascinating for these reasons but also that it's a product of its time in two main ways:

1. It doesn't do anything about roaming because that wasn't an issue in the 1990s but it certainly is now;

2. A 64 bit address space would've basically been infinite addresses but instead they went with 128 bit addresses (rolling in ports) but then giving individual users a /64 address range. For some reason people deny it now or simply weren't aware but that too is a historical artifact because it was intended to put a 48 bit MAC address into that space but later we realized that's a huge PII and tracking issue; and

3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.

That's interesting because it violates Postel's Law [2], which basically says be liberal in what you accept and conservative in what you send.

But this shows up in all sorts of interesting ways, like it's practically impossible to reliably use MTUs larger than about 1536. When IPv4 was designed, that wasn't an issue. With 1-100G+ networks it is. There are RFCs about using large MTUs but you're dependent on backbone hardware you have no control over.

Even Linux struggles with this, to the point where you need to do some configuration for high-bandwidth networks (eg RPS [3]). Just handling all those interrupts presents a bunch of problems beyond the original scope. And again, it's hard to fix through no fault of Linux's.

I'm old enough to remember the talk about us running out of IPv4 addresses back in the 1990s. It's been interesting to watch how this has consistently been kicked down the street (eg cgNAT).

What is funny though is large companies (eg Facebook) actualy ran out of internal addresses on a 10/8 network and there's no good solution for that (with IPv4 at least).

[1]: https://en.wikipedia.org/wiki/Second-system_effect

[2]: https://en.wikipedia.org/wiki/Robustness_principle

[3]: https://lwn.net/Articles/362339/

Re: IPv6 is the only way forward

#57
I honestly don't understand why IPv6 is not actively deployed in 2026. Every piece of networking hardware over past decade supports IPv6 and often dual stack too. And to switch between both often takes a few clicks if DHCPv6 server is up and reachable. Absolutely transparent, free, zero performance hit. But no, so many persist at doing v4.

PS: I'm talking about MSO hardware. But client hardware should be at the same level of compatibility for years too.

Re: IPv6 is the only way forward

#58
post #23

Earlier quoted context omitted.

IPv6 cannot be backward-compatible with IPv4 in the way UTF-8 is with ASCII. Any argument built on that comparison reflects a misunderstanding of the protocols and leads to flawed conclusions.

Why not? Sincere question. As a very superficial idea, if we go back to the drawing board, for example we could decide our new cool concept of address to be an IPv4 + an hex suffix, maybe at the expense of not having a humongous address space. So 10.20.30.40 would be an IPv4 address, and 10.20.30.40:fa:be:4c:9d could be an IPv6 address. With the :00:00:00:00 suffix being equivalent to the IPv4 version. I just made th…

Programmers really like to focus on things like:

- How they would format the display of the bits

- Where in the bit pattern IPv4 mapped addresses should go

- Coming up with some variation of NAT64, NAT464, or similar concepts to communicate between/over IPv4 and IPv6 networks

- Blaming the optional extensions/features of IPv6 for being too complex and then inventing something which has 90% of the same parts which are actually required to use

It's even easy to get distracted in a world of "what you can do with IPv6" instead of just using the basics. The things that actually make IPv6 adoption slow are:

- A change in the size of the address field which requires special changes and configuration in network gear, operating systems, and apps because it's not just one protocol to think about the transport of again until the migration is 100% complete.

If IPv4 were more painfully broken then the switch would have happened long ago. People just don't care to move fast because they don't need to. IPv6 itself is fine though and, ironically, it's the ones getting the most value out of the optional extensions (such as cellular providers) who actually started to drive IPv6 adoption.

Re: IPv6 is the only way forward

#59
post #35

Earlier quoted context omitted.

Wait, why couldn't it? Just split the address into two 32-bit chunks (call the top word the "pool", bottom word "address") and assign the full IPV4 range to pool 0x00000000. Done.

Well for starters, IPv6 has 128 bit addrs. But then think about what the routing tables would look like, how would an IPv4-only host find an IPv6 host not in pool 0? You'd be reinventing NAT, but in a less-structured context than how NAT works today. There's more issues to it too. If it was really that simple they would have done exactly that. "Just adding more bits to IPv4" just isn't possible to do backwards-compat…

>how would an IPv4-only host find an IPv6 host not in pool 0?

Ah.

Re: IPv6 is the only way forward

#60
post #57

I honestly don't understand why IPv6 is not actively deployed in 2026. Every piece of networking hardware over past decade supports IPv6 and often dual stack too. And to switch between both often takes a few clicks if DHCPv6 server is up and reachable. Absolutely transparent, free, zero performance hit. But no, so many persist at doing v4. PS: I'm talking about MSO hardware. But client hardware should be at the same…

2026:

  $ ping6 github.com
  ping6: github.com: Address family for hostname not supported
Post reply on HN