News for hackers. Stuff that matters.

A comment on Reclaiming IPv4 Class E's 240.0.0.0/4. Parent comment

Re:Reclaiming IPv4 Class E's 240.0.0.0/4 by jedberg on Monday May 27, 2024 @01:49PM (#40492971)
They don't. They still have to upgrade. But at least the service owner has options to run the services on their gateway and then pass the traffic back to the hosts behind on their internal IPv6 network.

And more importantly it means that if a client wants to interact with IPv6, they only have to upgrade their client, and not wait for everyone in between to upgrade too.

[ Parent | on HN ]
Re:Reclaiming IPv4 Class E's 240.0.0.0/4 by jcranmer on Monday May 27, 2024 @02:14PM (#40493154)
In other words, your proposal establishes only not-IPv4<->not-IPv4 communication over an IPv4 tunnel, which is something actual IPv6 has had for decades?

(There's also the interesting question of how not-IPv4 addresses are supposed to get their not-IPv4 addresses if the entity they get their IP addresses from doesn't support not-IPv4.)

[ Parent | on HN ]
Re:Reclaiming IPv4 Class E's 240.0.0.0/4 by jedberg on Monday May 27, 2024 @02:17PM (#40493174)
No, it establishes a path for piecemeal upgrades to the infrastructure that is cross compatible with IPv4.
[ Parent | on HN ]
Re:Reclaiming IPv4 Class E's 240.0.0.0/4 by jcranmer on Monday May 27, 2024 @02:28PM (#40493281)
I'm not seeing it... can you clearly explain specifically what scenarios your not-IPv4 deployment strategy enables that doesn't exist with IPv6 today?

(If you're going to say "not-IPv4 local network with IPv4 ISP", then clearly explain how the not-IPv4 local network is supposed to get its not-IPv4 address, and why that is materially different from existing IPv6 tunnel options.)

[ Parent | on HN ]