Ah. So, you're saying that what you describe doesn't actually exist. That the best you can currently do is stuff like [0] and [1] where the IPv4 or IPv6 client use v4 or v6 addresses (respectively) and an intermediary sets up a fake destination IP on both ingress and egress and does the v4 <-> v6 address translation.

If so, that was not at all clear from your original comment.

[0] <https://docs.fortinet.com/document/fortigate/7.6.1/administr...>

[1] <https://docs.fortinet.com/document/fortigate/7.6.1/administr...>

> Very few, in my prediction.

Sure, I agree. I'm not sure how you got the notion that I thought a large percentage of systems out there will never get IPv6 support. There's a lot of solid systems out there that just fucking run. They're a small percentage of all of the deployed machines in the world.

> That's still what I would call a v6-only (with translation mechanisms) client deployment.

When people say "IPv6 only", they mean "Cannot connect to IPv4 systems". IMO, claiming it means anything else is watering down the definition into meaninglessness. Consider it in the context of what someone means when they envision a future where the Internet is "IPv6 only", so we don't need to deal with the "trouble" and "headache" of running both v4 and v6.

> We're already seeing massive v6 + CG-NAT-only deployments these days...

Yeah, it's my understanding that that's been the situation for a great many folks in the Asia/Pacific part of the world for a while now. Lots and lots of hosts, but not much IPv4 space allocated.

> I entirely disagree. Due to a combination of ISPs sticking with what they know and refusing to update... and vendors minimising their workloads/risk exposure and only updating what they "have to"...

You misunderstand me, though the misunderstanding is quite understandable given how I phrased some of the things.

I expect the updating usually occurs when buying new kit, rather than on kit that's deployed... and that that purchasing happens regularly, but infrequently. I'm a very, very big proponent of "If it's working fine, don't update its software load unless it fixes a security issue that's actually a concern.". New software often brings new trouble, and that's why cautious folks do extensive validation of new software.

My commentary presupposed that

  [Y]ou're adding support for a new Internet address protocol that's widely agreed to be *the* new one

> I think it's much easier to update consumer edge equipment. The ISP dictates all aspects of this relationship...

I expect enough people don't use the ISP-rented equipment that it's -in aggregate- actually not much easier to update edge equipment. That's what I was trying to get at with talking about "ISP-provided routers & etc are crap and not worth the expense".

> The old IP addresses (afaiu/ime) will not be removed before any dependent connections are removed.

I have two reactions to this.

1) Duh? I'm discussing a failover situation where your router has unexpectedly lost its connection to the outside world. You'd hope that your existing connections would fail quickly. The existence of the deprecated IP shoudn't be relevant because the OS isn't supposed to use it for any new connections.

2) If you're suggesting that network-management infrastructure running on the host will be unable to delete a deprecated address from an interface because existing connections haven't closed, that doesn't match my experience at all. I don't think you're suggesting this, but I'm bringing it up to be thorough.

> ...the OS APIs for this stuff just aren't descriptive enough to describe the network reconfiguration event.

I know that Linux has a system (netlink?) that's descriptive enough for daemons [0] to actively nearly-instantaneously start and stop listening on newly added/removed addresses. I'd be a little surprised if you couldn't use that mechanism to subscribe to "an address has become deprecated" events. I'd also be somewhat surprised if noone had built a nice little library over top of whatever mechanism that is. IDK about other OS's, but I'd be surprised if there weren't equivalents in the BSDs, Mac OS, and Windows.

> In any case, this vision of the world misses on at least two things, in my view:

> 1. Administrative load balancing...

I deliberately didn't talk about load balancing. I expect that if you don't do that at a layer below IP, then you're either stuck with something obscenely complicated or you're doing something like using special IP stacks on both ends... regardless of what version of IP your clients are using.

> 2. The long tail of devices that don't respond well to the flow you outlined.

Do they respond worse than in the IPv4 NAT world? This and other commentary throughout indicates that you missed the point I was making. That point was that -unlike in the NATted world- the OS and the applications running in it have a way to plausibly be informed of the network addressing change. In the NAT case, they can only infer that shit went bad.

[0] ...like BIND and NTPd...

If your edge router supports IPv6, it almost certainly can make a DHCPv6-PD request and handle advertising the assigned prefix on its LAN side.

Because of Google's continued (deliberate?) misunderstanding of what DHCPv6 is for, Android clients don't do anything sane with it. That doesn't mean that DHCPv6 isn't simple.

Again, DHCPv6 is "Please give me an IP address, and maybe also what my directly-attached friends need to get IP addresses.". Simple, straightforward, and easy to understand. Even if it were relevant, Google's chronic rectocranial insertion doesn't change that.