3 ms·

I don't think it's impossible per se. You could probably get around that limitation via a beefed up version of NAT, along with a couple DNS hacks. Obviously,

I don't think it's impossible per se. You could probably get around that limitation via a beefed up version of NAT, along with a couple DNS hacks. Obviously, that's some ugly hacky BS though. I think better design could have avoided that issue to begin with by facilitating smooth roll over. Still, I'd start with translating ipv4 addresses into a reserved range of ipv6 addresses. ...and if ipv4-only clients can't initiate new connections to ipv6 addresses outside that range, OH WELL. (There's probably wiggle room to NAT your way through anyway) More importantly, if there's a default in-built way for ipv6-only machines to initiate connections to ipv4-only machines, and the ipv4 machines can return traffic via some type of NAT, there's a lot more incentive to switch to support ipv6 since more machines would be using it.

JonathonW 5y ago
What you describe there is basically NAT64 [1]. Not a ton of reason to actually deploy NAT64, though, when practically everything's going to be dual-stack anyways and you're not saving any IPv4 addresses versus that dual-stack arrangement with a typical IPv4 NAT. (There are also compatibility issues to consider; not everything can work with IPv6 addresses at the application level, especially early on in the transition.) [1] https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64
windexh8er 5y ago
> ...via a beefed up version of NAT... This is generally referred to as CGN, or Carrier Grade NAT. Article on CGN from 2011, as an example [0]. [0] https://www.lightreading.com/ethernet-ip/the-ugly-side-of-ipv6-carrier-grade-nat/d/d-id/687459 https://www.lightreading.com/ethernet-ip/the-ugly-side-of-ip...
gary_0 5y ago
> translating ipv4 addresses into a reserved range of ipv6 addresses That's already a part of IPv6: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_IPv4 https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I... (In fact, when I store IPv4 addresses in memory/files, I just use the IPv6 encoding, which saves having a separate IP version field.)

JonathonW 5y ago

What you describe there is basically NAT64 [1]. Not a ton of reason to actually deploy NAT64, though, when practically everything's going to be dual-stack anyways and you're not saving any IPv4 addresses versus that dual-stack arrangement with a typical IPv4 NAT. (There are also compatibility issues to consider; not everything can work with IPv6 addresses at the application level, especially early on in the transition.) [1] https://en.wikipedia.org/wiki/NAT64 https://en.wikipedia.org/wiki/NAT64

windexh8er 5y ago

> ...via a beefed up version of NAT... This is generally referred to as CGN, or Carrier Grade NAT. Article on CGN from 2011, as an example [0]. [0] https://www.lightreading.com/ethernet-ip/the-ugly-side-of-ipv6-carrier-grade-nat/d/d-id/687459 https://www.lightreading.com/ethernet-ip/the-ugly-side-of-ip...

gary_0 5y ago

> translating ipv4 addresses into a reserved range of ipv6 addresses That's already a part of IPv6: https://en.wikipedia.org/wiki/IPv6_address#Transition_from_IPv4 https://en.wikipedia.org/wiki/IPv6_address#Transition_from_I... (In fact, when I store IPv4 addresses in memory/files, I just use the IPv6 encoding, which saves having a separate IP version field.)