I spent a week without IPv4 to understand IPv6 transition mechanisms

A reader who's actually interested in getting the source, might try Googling for "2070.43", or even "2070.43 million wifi". I must admit, I wasn't serious enough about my comment to spend $3,250 on the whole report, and had to go off of the public preview. Since you seem to be more serious, maybe you could pay the $4,400 for a multi-user licensed copy of the report and share the PDF with me? I'd love to read more of the analysis.

So, I mean, I dunno, 2 billion dollars seems serious to me, but maybe we just have different barometers for what counts as "serious amounts of money". Especially considering these devices that are like $300.

Finally, might I remind you of the guidelines? in particular:

> When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3."

https://news.ycombinator.com/newsguidelines.html

I would love full transitions to be easy enough to work. DNS64 breaks DNSSEC without updates to the spec, so that's not going to fly for me today. A competent DNS configuration would fail to resolve my IPv4 domains at the very least (though all of my public domains have an AAAA record, obviously). The only solution is to do DNSSEC validation at the DNS64 level which in my opinion defeats the purpose of DNS security all together.

For internal networks, IPv6 seems like an obvious choice. If you already have company wide subnets, you may as well set up some ULAs/GUAs and use IPv6 internally. Full IPv6 may be better but people worry about adversaries mapping internal networks for some reason so NAT66 may be necessary to placate those fears.

The problems you still keep around by using some kind of dual stacking (DS-Lite being the cheapest) ensures compatibility with servers and entire countries that haven't even begun upgrading their networks yet. You incur the IPv4 penalty, for sure, but only towards services that don't have IPv6. This provides an incentive for the world to move on without breaking existing infrastructure entirely.

> v4 addresses become ever more expensive and the cost of CG-NAT deployments continue to climb.

But IPv6 is not an alternative to CGNAT. If you don't provide either a routable IPv4 or CGNAT, your customers will ask their money back because their internet is broken. The fact that you provide IPv6 or not is completely irrelevant to the vast majority of consumers or businesses.

This here is the major failure of IPv6 design, confusing what "the internet as a whole and the ISP community" need, with the individual incentives that make a single ISP provide for those needs.

I still don't think you're really providing any examples or arguments that make your point, though. You're just coming across as really salty about IPv6. I'm not downvoting you.

IPv6 has link-local addresses that aren't routable, so you can't really get more local than that. Unlike a typical IPv4 setup, typical IPv6 hosts have multiple addresses, and you can make your own for local traffic and only rely on ISP prefixes for internet access if you want to.

Sure, the internal host's internet routable IP address is visible rather than being masked behind the router's IP address. Pretty much all operating systems periodically randomize the bottom 64 bits, making it effectively as opaque as NAT. You could call that a hack, but people call NAT a hack. There's tradeoffs.

The CVE links you provided are just lists of vulnerabilities with "firewall" in the name. Skimming through them, I don't see how they're specific to IPv6? Most of the vulnerability descriptions I read seem equally problematic for NAT setups. The one IPv6 specific one I saw had to do with a bad firewall rule allowing access to LAN facing services running on the router; it could have just as easily been a bad IPv4 rule.

I agree, consumer network gear all sucks. IPv6 is bolted on as an afterthought, and is probably buggy in a lot of them. More features means more opportunity for bugs, but that's true of anything. IPv6 isn't being deployed for no reason; there's limited IPv4 addresses to go around. I still don't follow why IPv6 is fundamentally riskier than IPv4 when traversing a router. Sure, with NAT an incoming packet needs to have a port number that's been dynamically mapped back to an internal host and port, or have a static port forward. In IPv6, an incoming packet needs to have a destination address and port that's been dynamically mapped back to an internal host and port, or have a static firewall rule. It's basically the same, but also less complicated for the router because there's no translation involved. In time, less complexity is good for software hardness.

I also get anxiety from trying to wrap my head around IPv6 address assignment. It is nuts. It's very comforting to work in the effectively 8-bit address space of a /24 IPv4. I suppose it's true that you can't control internet routable IPv6 addresses in that they are dynamic and ephemeral in their nature. Coming from IPv4, it feels messy. I've experimented in detail with configuring my own ULA, DHCPv6 configuration, and SLAAC. I've tried to embrace the benefits of IPv6, and having used a few of the features I can appreciate them for what they are.

The point is until everyone moves to IPv6, the rest of us are stuck having to support dual stack - which is expensive (see the recent story about an ISP supporting a tribal reservation who had to spend an extra $300k and wait 11 months to support legacy IP) and introduces complexity/risk.

For a small network it makes no difference, everything is auto configured, mdns is used to lookup names, you can makes your hosts ::1 ::2 etc if you want to. Many ISPs around the world provide IPv6 by default, and users are using it without even realising, so it is being adopted just not fast enough. Global usage is around 42% based on published stats, and is well over 50% in many countries, as high as 80% in some.

IPv6 does provide benefits to end users, it reduces cost for the ISP and makes end to end connectivity viable which opens up a whole new set of opportunities. End to end is immensely beneficial for gaming, voip etc. Having everything centralised because users are encumbered by NAT is a big problem - increased latency, high costs (recouped from the users somehow - eg selling their data), single point of failure, applications which become useless once the central servers are shut down etc.