4 ms·

the trick is actually to add the extra bytes on the back end. 192.168.8.9.0.1.2.3 old devices get accessed the old way. new devices "know" about the add ons.

the trick is actually to add the extra bytes on the back end. 192.168.8.9.0.1.2.3 old devices get accessed the old way. new devices "know" about the add ons. The new part of the address travels inside "as data" so it gets delivered. as company firewalls and routers switch to new, the whole company needs only one "old" ip. To get the ball rolling, spend some time deploying before it's switched on. All those early adopters who have class A networks? They can go first this time too, freeing up their class A's quickly to facilitate the transition for everybody else. source: this was my idea for phone numbers back when they kept rejiggering area codes.

Dylan16807 3y ago
This avoids some core router upgrades, but if you're on a device with a long address then every service you talk to also needs to be upgraded to use the extra bytes. So it still has similar adoption problems. Unless you hide it all with NAT, but if you're doing that then you're losing lots of the benefits of more address space. And the NAT version is something you can already build yourself, but is rarely chosen for a reason.
- fsckboy 3y ago
  > Unless you hide it all with NAT, but if you're doing that then you're losing lots of the benefits of more address space. it enables a graceful transition period
  - Dylan16807 3y ago
    What's the incentive to actually set it up, though? You can do it right now as a graceful transition to IPv6. Running a pure IPv6 network with NAT64 or similar. But almost nobody does it. Why would your scheme be more tempting to them?
p1mrx 3y ago
You're roughly describing 6to4, where 2002:c0a8:0809::123 belongs to 192.168.8.9. Though 6to4 is mostly deprecated, and you generally don't use it with "private" IPv4 addresses, unless you're incrementally deploying IPv6 in an environment where half the switching fabrics are IPv4-only and the other half can do hardware-encap/decap 6to4 but not 6rd.

Dylan16807 3y ago

This avoids some core router upgrades, but if you're on a device with a long address then every service you talk to also needs to be upgraded to use the extra bytes. So it still has similar adoption problems. Unless you hide it all with NAT, but if you're doing that then you're losing lots of the benefits of more address space. And the NAT version is something you can already build yourself, but is rarely chosen for a reason.

fsckboy 3y ago
> Unless you hide it all with NAT, but if you're doing that then you're losing lots of the benefits of more address space. it enables a graceful transition period
- Dylan16807 3y ago
  What's the incentive to actually set it up, though? You can do it right now as a graceful transition to IPv6. Running a pure IPv6 network with NAT64 or similar. But almost nobody does it. Why would your scheme be more tempting to them?

p1mrx 3y ago

You're roughly describing 6to4, where 2002:c0a8:0809::123 belongs to 192.168.8.9. Though 6to4 is mostly deprecated, and you generally don't use it with "private" IPv4 addresses, unless you're incrementally deploying IPv6 in an environment where half the switching fabrics are IPv4-only and the other half can do hardware-encap/decap 6to4 but not 6rd.