3 ms·
OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing. If there is that magic IPV4
by AtlasBarfed 3y ago
OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing.
If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP.
... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path.
... that might not work ... or maybe it will?
- greyface- 3y agoYou've reinvented 6to4 and the 192.88.99.1 well-known anycast address.
- AtlasBarfed 3y agoSo I think the difference here is then is gradual migration of the same IP stacks / infrastructure, and not introducing an entirely new "separate" stack. My only experience with IPv6 was converting an IPV4 distributed database to IPV6. It wasn't... fun. Looking up separate flags and settings, weird errors (thank the gods for stack overflow), frustration. Nowhere was it suggested, demonstrated, or detailed such a backwards compatibility / migration strategy.
- Dagger2 3y agoThat's what we have with v6. It's not entirely separate; it tends to be implemented together with v4 in the same stack of code and deployed on the same infrastructure. It's designed to allow you to migrate gradually. > My only experience with IPv6 was converting an IPV4 distributed database to IPV6 I assume you mean patching the software to handle it... there are basically two socket APIs, the old one which was v4-only and the new one which works with any generic IP family. v6 had to add the second one because the first one was v4-only, but any replacement protocol for v4 would have had to do the same.