upvote
If your solution is that “if everyone just used IPv6 we wouldn’t have this problem” then it’s not a solution. Standards like USB, Wi-Fi, HDMI, DP, etc. are so successful because they are by out-of-the-box backwards compatible with their predecessors.
reply
>HDMI, DP, etc. are so successful because they are by out-of-the-box backwards compatible with their predecessors

Takes on Hacker News can truly be wild sometimes.

I certainly don't recall being able to use DP on a VGA monitor without some sort of adapter!

reply
You missed the part where DP didn't come with it's own Audio Codec and GPU architecture. Of course, I am exaggerating, but the point is that the problem with IPv6 is not just that it suffers from bad design on merit, it also critically suffers from scope creep. We wanted a larger IP space, instead we got network discovery and globally unique cookies as a bundle deal, with a whole lot of other crap.
reply
> There's nothing wrong with ipv6 other than [long list of human things]

The unfortunate reality is that technology exists to serve us. If humans don't want to use it, it means that your technology is wrong. End of story. It doesn't matter if you (or any of us) think it's elegant and beautifully designed.

reply
Declaring a technology-in-transition dead is truly a take.

It's like declaring SSL/TLS dead in 2012 because some websites were not using it. (Yes, I remember the dark times when even authentication data was transmitted over plain text.)

reply
My first job out of college passed the authentication over SSL/TLS, but the page that *contained* the login form? That was sent in the clear.... Truly dark days.
reply
> This literally exists. There's no need for it to be part of the original specification because it's a completely separate concept.

By that token, IPv6 never had to exist at all then, but we know that is completely missing the point.

IPv6 is a privacy nightmare without privacy extensions. It is designed with "a stupid desire to pretend we can boil the ocean".

Close to 3 decades and we are barely scraping 50%: https://stats.labs.apnic.net/ipv6/

reply
Running a IPv6-only network that doesn’t interact with IPv4 networks in any way is great and it works.

The actual gap is the mess of mixing/transitioning, and it wasnt planned properly in the last 30years

reply
Yeah, that is the whole point. It was never going to be a clean cut. "Works in my lab" isn't good enough for real world.

The issue isn't that it wasn't planned properly, the issue is that the real world wasn't taken into consideration by people who either worked for the likes of Google who were aching for a globally unique identifier per device or just delusional about how much we can change in real world.

reply
> Yeah, that is the whole point. It was never going to be a clean cut.

As predicted:

      We believe that it is not possible to have a "flag-day" form of
      transition in which all hosts and routers must change over at
      once. The size, complexity, and distributed administration of the
      Internet make such a cutover impossible.

      Rather, IPng will need to co-exist with IPv4 for some period of
      time.  There are a number of ways to achieve this co-existence
      such as requiring hosts to support two stacks, converting between
      protocols, or using backward compatible extensions to IPv4.  Each
      scheme has its strengths and weaknesses, which have to be weighed.

      Furthermore, we note that, in all probability, there will be IPv4
      hosts on the Internet effectively forever.  IPng must provide
      mechanisms to allow these hosts to communicate, even after IPng
      has become the dominant network layer protocol in the Internet.
* https://datatracker.ietf.org/doc/html/rfc1726#section-5.5

Creating an IPng was always going to be complicated:

      So it's a matter of mathematical and physical fact that to expand
      the address size, you must change the protocol, and that means 
      [three] things immediately:

            You have to change the version number.

            You have to add new code to handle the new version.

      […]

            You need a coexistence technique so that updated systems, 
            with the new protocol, can connect to old systems that know 
            nothing of the new protocol.

      Two minutes of thought show that this third requirement has only 
      two solutions:

            (3A) Dual stack, in which the new machines speak both 
                 the old (IPv4) and new (IPng) protocol.

            (3B) Translation, in which something translates addresses
                 between the old and new protocols.

* https://github.com/becarpenter/misc/blob/main/why6why.md

* https://datatracker.ietf.org/doc/html/rfc1671

reply
[dead]
reply
> without privacy extensions

Privacy extensions are enabled by default on every major operating system.

reply
> There's nothing wrong with ipv6

Sweet summer child...

There's EVERYTHING wrong with IPv6. It's a recursively bad protocol. From the basic header design (extension headers, wtf) to the "human management" layer ("why should we deploy IPv6 if it actively _breaks_ stuff?").

As an example, try to design a standards-compliant IPv6 network where you can reliably print from an Android phone if your Internet connection goes down and the router withdraws the prefix. It's trivial with IPv4 and _impossible_ with IPv6.

reply
> if your Internet connection goes down and the router withdraws the prefix

My router advertises both the public prefix from my ISP and a ULA prefix for internal LAN connections (essentially the IPv6 equivalent to RFC-1918). This gives me stable local addresses that do not change and work without public internet access.

https://en.wikipedia.org/wiki/Unique_local_address

reply
> My router advertises both the public prefix from my ISP and a ULA prefix for internal LAN connections

You'd think so, but you'd be wrong. If you have a GUA and a ULA, and the printer has both a GUA and a ULA, then your host is going to prefer the GUA when connecting to the printer.

So when a router withdraws a prefix, it's possible for your computer to still have a (stale) GUA while the printer only has a ULA. Whoops, and your printing is broken.

There is an RFC in review that would fix this: https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda... . It'll likely be approved in 2027, so you'd be able to use ULAs some time in the 2030-s once it trickles down.

reply
That RFC does look like a nice improvement! Until then, since both devices have a ULA address, wouldn't simply deleting the printer from your phone/computer and re-adding it resolve the issue? Doing it when your public internet is down would probably even be best to ensure you're getting the ULA instead of GUA, thereby avoiding this issue entirely in the future.

(Admittedly I haven't had a printer for over a decade and I have never printed from a phone, so maybe I am missing something.)

reply
In practice, nobody uses IPv6 for printers, so it'll work just fine over IPv4.

I used a printer as an example of a local device, it can be any other device: a smart lightbulb, a TV you're casting to, a SIP phone, etc. And I used Android as an example of a device where you can't easily change the source address selection preference.

What is more shocking is that this problem has been known for three decades, yet somehow nobody cared enough to fix it. And it's far from the only issue.

reply
Ditch advertising public addresses to local devices at all.

Have the router issue ULAs only and let the router do stateless NPT (network prefix translation) only.

Done, works great. Doesn’t matter what your internet connection is doing.

Yes, your local devices will use the ULA to attempt to connect to Internet destinations if that’s the only v6 address they have. It works fine.

reply
While this is going to be fine for many users, wouldn't this continue our reliance on STUN for UDP hole punching? I'd certainly prefer a world where peer-to-peer networking is less reliant on work-arounds created for the NAT era.
reply
> Have the router issue ULAs only and let the router do stateless NPT (network prefix translation) only.

This is an option, but ULAs are ranked _below_ IPv4 in address selection preferences. So your network will essentially operate in IPv4 mode: https://www.ietf.org/archive/id/draft-buraglio-6man-rfc6724-...

Moreover, some devices will refuse to connect to IPv6 GUA with ULA addresses altogether.

> Yes, your local devices will use the ULA to attempt to connect to Internet destinations if that’s the only v6 address they have. It works fine.

You're half right. The devices will work fine because they won't be using IPv6 at all.

As I said, IPv6 is a recursive WTF.

How do I know that? I made a personal goal to create a dualstack demo network that is fully standards compliant and supports the bare minimum functionality that I would expect from a SOHO network. So far, I keep finding new and exciting breakages on every level.

reply
> This is an option, but ULAs are ranked _below_ IPv4 in address selection preferences. So your network will essentially operate in IPv4 mode

If they don’t have an v4 address then they don’t have that problem.

NPT solves the issue of your devices losing global addresses.

Ideally you wouldn’t need NPT, and you should have an RA for the ULA and an RA for the GUA and then use the ULA locally... but then you end up with a different problem (and why I didn’t do it at home). Doing this means you have little control about which upstream ISP gets chosen. I have two ISPs at home, and router will failover between them; however, even though I have PI IP space, finding a residential ISP that will let me use it is nearly impossible (good luck finding someone there who even knows what BGP is).

So the tradeoff here for me is not letting my devices have a GUA so that my router can control outbound traffic policy completely (like it can with v4), and just NPT it to what I need it to be externally. Works great (but again, if you only have one global prefix you need to deal with, separate RAs for ULA/GUA do work better).

> You're half right. The devices will work fine because they won't be using IPv6 at all.

Not if they don’t have an IPv4 address to begin with!

You can also coax your local DNS resolver to... just not let A records through if the name also has an AAAA record.

Even better than that would be out of the box like magic 464XLAT in home routers / ISPs. As it is 464XLAT is not the nicest thing in the world to configure; however, it does work very well, and does allow for a network to be entirely v6 except at the very edge. Heck, I’d love it if enterprise gear had “like magic” 464XLAT too. Would make a lot of things easier.

> How do I know that? I made a personal goal to create a dualstack demo network that is fully standards compliant and supports the bare minimum functionality that I would expect from a SOHO network. So far, I keep finding new and exciting breakages on every level.

If you really want to accomplish that, completely forget about trying to make dual stack work throughout the network. It’s an exercise in frustration, mostly in needing to duplicate config in v4 and v6, and you will inevitably have them end up out of sync with each other.

464XLAT is good standard here, DNS64 with a NAT64 does also work... for things with names at least.

One of the other comments around here about not providing a “migration plan” does have a lot of truth to it. If, 30 years ago, they envisioned 464XLAT and made it part of the default features a v6 capable router should have, I bet v4 would be long dead (or nearly there) by now.

reply
The extension headers are fine, because they frequently are not needed, so the fact that they are optional allows the IPv6 header to be significantly simpler than the IPv4 header, which has some seldom used fields which are always present.
reply
No, they are not fine. Their design means that the router needs to know all possible extension headers to just be able to route the packets. Oh, and you also have to do offset-chasing in the hardware fastpath.

As a consequence, IPv6 with extension headers are just dropped by routers in the public Internet.

reply
deleted
reply
If it works with mainstream Linux, sounds like an Android problem
reply
That's not a very good example.

1) I can count on one hand the number of times my Internet connection has gone down in the past 5 years.

2) I can count on zero hands the number of times I've tried to print from a phone, ever.

reply
I explained the problem in a sibling post on this thread.

But you want a more complex challenge? Here you go!

You have a small business office that has two Internet uplinks for redundancy. You want to balance the load across them and failover broken links.

This can be done with literally zero setup with IPv4.

reply
I do admit this is a challenge. The only reason it's "easy" with IPv4 is because of NAT. With IPv6 you'll need prefix translation. I've found someone with a failover solution for UniFi but in general you are correct, it's a pain: https://github.com/mattackerman808/ipv6-wan-failover
reply