Also, really? You think that Internet-facing software in inverters is a big deal?

For most drugs the only reasonable test animals are mice and rats. And they LOVE to naturally get cancer and other diseases, so you need to use large groups to get even a semblance of statistical significance.

Oh, and don't forget that it takes a lot of time to run the tests. And time IS money for pharma.

I was kinda expecting: "And when my agent built a perfect clone of Instagram and social-engineered all my contact list to join"

https://www.elwha.org/wp-content/uploads/2026/01/Spatial-Spa...

> While annual estimates of the proportion of hatchery-origin natural spawners (pHOS) were initially 94-97% during and immediately following dam removal (2014-2019), pHOS declined to 82-85% during 2020-2024 (Weinheimer et al. 2022, WDFW unpublished).

And the absolute numbers are also not that great.

Elwha dam removal was a no-brainer as it was entirely useless. But it does cast doubt on the efficacy of larger dam removal projects, they are not necessarily going to result in automatic recovery.

WA is also spending about $10B on improving culverts on smaller streams. So far this hasn't resulted in meaningful effects on salmon runs. These moneys would be much better spent on other environmental projects.

The biggest success so far was in the Klamath River watershed.

Dams can make rivers more resilient.

Carriers have their own specific challenges. Like not having enough private or even squattable IPv4 space for the voice circuits.

> If mobile carriers can do it, and support $billions of devices, it does work, and works well.

Mobile devices are actually pretty much the best case for IPv6. The phone environment is standardized and highly controlled. And yet some telecoms still don't provide end-user IPv6, even when the voice circuits use IPv6.

> No one should be using NAT with v6 except in extremely limited circumstances. NPT is not NAT, the host portion of the network and, more importantly, the port do not change with NPT.

This is really a distinction without difference. In practice, SOHO border routers have to be stateful to provide meaningful security for UDP-based protocols like SIP or QUIC.

> That is effectively how it works, they can coexist together, but it is significantly simpler to only use one.

The socket API still doesn't allow this. You have to implement Happy Eyeballs on the app level.

> I do agree with you on the ULA priority though. Was a moronic decision to place that below v4, likely again, a lack of imagination on their part.

If you want to look at politics, this was a compromise. There was a strong faction of "network fundamentalists" in the IETF that had a vision of a transparent end-to-end network with global addressing. So that a lightbulb in China could connect to a toaster in the US at will. So they resisted anything that could promote locally isolated networks.

But most of the IETF had a clue and actual operational experience, so they pushed for things like the ULA and PI space for IPv6. So we got these compromises that don't work well as a result.

And it's more of the "it's the thought that counts" thing. Multihoming was considered to be something rather exotic and mostly a requirement for ISPs or large companies.

The issue is that the extension headers can be used for nefarious purposes, such as hop-by-hop routing. So your fast hardware-based border routers might be EH-agnostic and transmit packets to your core network. And then a helpful Linux box that implements all of IPv6 in software would reflect the traffic right past your firewall.

Implementing the EHs in hardware is expensive, as you need to do conditional checks. So routers just drop them.

The needs for dual-homing and failover were completely glossed over in the IPv6 design, and the IETF has not acknowledged these needs even to this day.

But anyway, ULA vs. GUA preference is mostly an academic question. In practice, you can just squat on an unused IPv6 range and avoid the precedence issue.

The deeper problem is that the solution to IPv6 problems appears to be NAT. And we're switching from IPv4 to avoid NAT. And you'll need a stateful firewall for IPv6 anyway (it's a recommendation for SOHO, there's an RFC for it, too lazy to dig it up now).

I'm stubborn, so my house now has its own ASN, a PI block, and a DIA connection to two ISPs. Which is the only NAT-less way to achieve my goal.

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

464XLAT (and its evil twin IPv6 RD) were envisioned in the early 2000-s. Along with about 20 various "migration plans". They all missed the point, though. Some people are still missing it.

The key to migration has never been some form of tunneling. The key to migration is making IPv4 and IPv6 coexist side-by-side, in other words, the Happy Eyeballs algorithm. It should have been reified to the TCP level in the late 90-s. So that applications could just do: `connect("somehost.com", 80)` and transparently get either an IPv4 or IPv6 connection, depending on whichever one works better locally. Other operational headaches like the ULA priority would have surfaced much earlier then.

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.

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.

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.

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

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.

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.