4 ms·

Isn't it a little early for April Fools? This psychotic idea requires you to touch every stack out there. If you're going to touch every stack out there, then

Isn't it a little early for April Fools? This psychotic idea requires you to touch every stack out there. If you're going to touch every stack out there, then JUST DEPLOY IPV6 ALREADY.

schoen 5y ago
> If you're going to touch every stack out there, then JUST DEPLOY IPV6 ALREADY. But nearly "every stack" already supports IPv6 at a software level. Most of them have for more than a decade. I'd agree that, given a choice between implementing software support for any of our proposals in some platform and implementing software support for IPv6 in the same platform, it would be obvious that the latter should be a higher priority. But I've been trying to find platforms to which this would actually be a relevant consideration. So far it seems like the answer might be "a few CPE routers, and a few IoT software stacks". If anyone knows of more than this, I'd be glad to hear about it. More generally, I don't understand a way in which the behavior of "stacks" that could conceivably be updated is an important barrier to IPv6 adoption. Every device on my LAN, except the printer, already supports IPv6 well. I think my router does too. My ISP doesn't. We can't fix that with software upgrades.
- Hizonner 5y ago
  Your ISP isn't going to change its ingress or egress filtering of 127/8 either. Not in any reasonable amount of time.
- p1mrx 5y ago
  > My ISP doesn't [support IPv6]. We can't fix that with software upgrades. But we can fix that by not taking measures to increase the supply of IPv4 addresses. Scarcity makes IPv4 expensive, which then creates market pressure to deploy IPv6 sooner. For example, your ISP might notice that they hold valuable IPv4 assets, and migrate their network to IPv6+CGNATv4 in order to sell some of them off.
- Dagger2 5y ago
  But you can slow it down by making more v4 address space available. I'm of the general opinion that doing so would be a really bad idea. Let's focus our efforts on v6, not on efforts to delay v6.

Isn't it a little early for April Fools? This psychotic idea requires you to touch every stack out there. If you're going to touch every stack out there, then JUST DEPLOY IPV6 ALREADY.

schoen 5y ago

> If you're going to touch every stack out there, then JUST DEPLOY IPV6 ALREADY. But nearly "every stack" already supports IPv6 at a software level. Most of them have for more than a decade. I'd agree that, given a choice between implementing software support for any of our proposals in some platform and implementing software support for IPv6 in the same platform, it would be obvious that the latter should be a higher priority. But I've been trying to find platforms to which this would actually be a relevant consideration. So far it seems like the answer might be "a few CPE routers, and a few IoT software stacks". If anyone knows of more than this, I'd be glad to hear about it. More generally, I don't understand a way in which the behavior of "stacks" that could conceivably be updated is an important barrier to IPv6 adoption. Every device on my LAN, except the printer, already supports IPv6 well. I think my router does too. My ISP doesn't. We can't fix that with software upgrades.

Hizonner 5y ago
Your ISP isn't going to change its ingress or egress filtering of 127/8 either. Not in any reasonable amount of time.
p1mrx 5y ago
> My ISP doesn't [support IPv6]. We can't fix that with software upgrades. But we can fix that by not taking measures to increase the supply of IPv4 addresses. Scarcity makes IPv4 expensive, which then creates market pressure to deploy IPv6 sooner. For example, your ISP might notice that they hold valuable IPv4 assets, and migrate their network to IPv6+CGNATv4 in order to sell some of them off.
Dagger2 5y ago
But you can slow it down by making more v4 address space available. I'm of the general opinion that doing so would be a really bad idea. Let's focus our efforts on v6, not on efforts to delay v6.