5 ms·

IPv6 should have been designed to be backwards compatible and smoothly transition people over. Why not design it so you can just quietly migrate to ipv6 on the

IPv6 should have been designed to be backwards compatible and smoothly transition people over. Why not design it so you can just quietly migrate to ipv6 on the infrastructure side by introducing automatic translation of ipv4 packets into ipv6 and back by padding and removing zeros, and automatically reserving all the resulting ipv6 addresses to their ipv4 equivalent owners. This situation is the result of poor design and roll-out decisions, not the fault of everyone else.

duskwuff 5y ago
> IPv6 should have been designed to be backwards compatible Impossible. You can't communicate between two hosts without both hosts being able to address the other -- and there's no way for an IPv4-only host to pack 128 bits of address into a 32-bit host field.
- seiferteric 5y ago
  I wonder if you could use something like IP in IP (https://en.wikipedia.org/wiki/IP_in_IP https://en.wikipedia.org/wiki/IP_in_IP), basically just slap another IP header on your packet so your IP becomes two 32 bit IPs, one for your ISP and one for you.
  - duskwuff 5y ago
    That sounds really painful to work with, and it would still largely lack backwards compatibility -- hosts on both ends would need to be patched to support the "double address".
    - seiferteric 5y ago
      patching hosts would be easy, but the routers in between would probably not need any changes and that's big since it was one of the holdups of v6 deployment.
  - welterde 5y ago
    That exists for IPv6 in various variants: 6in4, teredo, 6to4, etc. (and the inverse variants of tunneling IPv4 over IPv6 also exist in many different forms). Many of those can be used even if your own ISP has no support for IPv6 at all. Many of the require manual configuration (as in the case of tunnel brokers) however, which makes it less likely for non-technical users to use them.
    - seiferteric 5y ago
      The idea would be to add first class support for it in the OS. Your ISP DHCP could add an addtional option specifying your upstream ISP address as well as your local address for example. Then your hosts interface will get configured with both addresses and automatically add wrap outgoing ip packets in the outer address.
      - welterde 5y ago
        This would also be possible with IPv6 (not with DHCP involvement, but with other mechanisms). But the issue is that some ISPs (and cloud providers) simply don't care or even actively drag their feet (since it may be in their business interest to do so for now).
- Enginerrrd 5y ago
  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.)
- windexh8er 5y ago
  IPv4 addresses can be converted to an IPv6 equivalent [0] and that can be used to keep the existing owned v4 blocks intact for protocol translation. What would have been nice is if standards would have forced migration of owned blocks and pressed Tier0 / Tier1 providers to handle "legacy" v4 traffic on ingress into their ASNs. Carriers are the driftpins in the equation here, they have to start the ball rolling and there needs to be an interop transition phase. All the pieces are there, there's just no incentive. [0] 10.10.10.10 == ::ffff:0a0a:0a0a
- im3w1l 5y ago
  Consider this: The OS reserves 10.0.0.0/8 for this purpose, possibly with a few common exceptions (10.0.0.0/16 maybe) being allowed through unmodified. If an ipv4 server has an incoming connection from an ipv6 address. That ipv6 address is given a corresponding 10.x.x.x address. Likewise, if an ipv4 client does a gethostbyname a 10.x.x.x address is allocated and returned. This simple system already supports 16m concurrent connections.
  - teraflop 5y ago
    Sounds like you're describing NAT-PT, originally proposed in RFC 2766 (published in 2000). It suffers from a lot of practical problems, which are described at length in RFC 4966. For example, without careful special handling it breaks protocols like FTP/SNMP/H.323 that embed IP addresses in data packets; it breaks IPsec; it can't handle fragmentation; and it suffers from scalability issues. https://datatracker.ietf.org/doc/html/rfc2766 https://datatracker.ietf.org/doc/html/rfc2766 https://datatracker.ietf.org/doc/html/rfc4966 https://datatracker.ietf.org/doc/html/rfc4966
    - deleted 5y ago
      [deleted]
    - im3w1l 5y ago
      > it breaks protocols like FTP/SNMP/H.323 that embed IP addresses in data packets Well it doesn't break them exactly. An ipv6 capable application would connect to the embedded ipv6 address and not be natted. But it fails to make a legacy application work, so you are no worse off at least.
akersten 5y ago
As I'm (slowly, begrudgingly) learning about IPv6 I can't help but agree. Astounding that backwards compatibility was abandoned in favor of ... Being able to hand out a /64 or /48 to anyone with a pulse? No residential customer needs that many addresses, yet I can call my ISP today and block that off for eternity. To what end? IPv6 should just have been a superset and 0..1.xxx.yyy.zzz.ttt should have been the legacy IPv4 space. I really don't get the point of all the bizarre block assignments, hexadecimal fetish, and general "why is this seemingly purposefully such a pain in the ass" feeling I get whenever I look at it.
- coolspot 5y ago
  IPv6 has like 4B * 65k ~= 260T (260,000,000,000,000) unique /48 addresses (subnets). Should be enough for every human on earth for sure.
  - kaliszad 5y ago
    It is something like one /48 for each second square meter of land on Earth or something in that ballpark. It definitely can be exhausted, but that is only because we more or less use the last 64 bit for grouping hosts, autoconfiguration etc. which doesn't have to be the case everywhere (e.g. container hosts, where giving each container or even a container host a /80 can be more than enough).
- pezezin 5y ago
  That legacy IPv4 already exists, it's ::ffff:0:0/96

duskwuff 5y ago

> IPv6 should have been designed to be backwards compatible Impossible. You can't communicate between two hosts without both hosts being able to address the other -- and there's no way for an IPv4-only host to pack 128 bits of address into a 32-bit host field.

seiferteric 5y ago
I wonder if you could use something like IP in IP (https://en.wikipedia.org/wiki/IP_in_IP https://en.wikipedia.org/wiki/IP_in_IP), basically just slap another IP header on your packet so your IP becomes two 32 bit IPs, one for your ISP and one for you.
- duskwuff 5y ago
  That sounds really painful to work with, and it would still largely lack backwards compatibility -- hosts on both ends would need to be patched to support the "double address".
  - seiferteric 5y ago
    patching hosts would be easy, but the routers in between would probably not need any changes and that's big since it was one of the holdups of v6 deployment.
- welterde 5y ago
  That exists for IPv6 in various variants: 6in4, teredo, 6to4, etc. (and the inverse variants of tunneling IPv4 over IPv6 also exist in many different forms). Many of those can be used even if your own ISP has no support for IPv6 at all. Many of the require manual configuration (as in the case of tunnel brokers) however, which makes it less likely for non-technical users to use them.
  - seiferteric 5y ago
    The idea would be to add first class support for it in the OS. Your ISP DHCP could add an addtional option specifying your upstream ISP address as well as your local address for example. Then your hosts interface will get configured with both addresses and automatically add wrap outgoing ip packets in the outer address.
    - welterde 5y ago
      This would also be possible with IPv6 (not with DHCP involvement, but with other mechanisms). But the issue is that some ISPs (and cloud providers) simply don't care or even actively drag their feet (since it may be in their business interest to do so for now).
Enginerrrd 5y ago
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.)
windexh8er 5y ago
IPv4 addresses can be converted to an IPv6 equivalent [0] and that can be used to keep the existing owned v4 blocks intact for protocol translation. What would have been nice is if standards would have forced migration of owned blocks and pressed Tier0 / Tier1 providers to handle "legacy" v4 traffic on ingress into their ASNs. Carriers are the driftpins in the equation here, they have to start the ball rolling and there needs to be an interop transition phase. All the pieces are there, there's just no incentive. [0] 10.10.10.10 == ::ffff:0a0a:0a0a
im3w1l 5y ago
Consider this: The OS reserves 10.0.0.0/8 for this purpose, possibly with a few common exceptions (10.0.0.0/16 maybe) being allowed through unmodified. If an ipv4 server has an incoming connection from an ipv6 address. That ipv6 address is given a corresponding 10.x.x.x address. Likewise, if an ipv4 client does a gethostbyname a 10.x.x.x address is allocated and returned. This simple system already supports 16m concurrent connections.
- teraflop 5y ago
  Sounds like you're describing NAT-PT, originally proposed in RFC 2766 (published in 2000). It suffers from a lot of practical problems, which are described at length in RFC 4966. For example, without careful special handling it breaks protocols like FTP/SNMP/H.323 that embed IP addresses in data packets; it breaks IPsec; it can't handle fragmentation; and it suffers from scalability issues. https://datatracker.ietf.org/doc/html/rfc2766 https://datatracker.ietf.org/doc/html/rfc2766 https://datatracker.ietf.org/doc/html/rfc4966 https://datatracker.ietf.org/doc/html/rfc4966
  - deleted 5y ago
    [deleted]
  - im3w1l 5y ago
    > it breaks protocols like FTP/SNMP/H.323 that embed IP addresses in data packets Well it doesn't break them exactly. An ipv6 capable application would connect to the embedded ipv6 address and not be natted. But it fails to make a legacy application work, so you are no worse off at least.

akersten 5y ago

As I'm (slowly, begrudgingly) learning about IPv6 I can't help but agree. Astounding that backwards compatibility was abandoned in favor of ... Being able to hand out a /64 or /48 to anyone with a pulse? No residential customer needs that many addresses, yet I can call my ISP today and block that off for eternity. To what end? IPv6 should just have been a superset and 0..1.xxx.yyy.zzz.ttt should have been the legacy IPv4 space. I really don't get the point of all the bizarre block assignments, hexadecimal fetish, and general "why is this seemingly purposefully such a pain in the ass" feeling I get whenever I look at it.

coolspot 5y ago
IPv6 has like 4B * 65k ~= 260T (260,000,000,000,000) unique /48 addresses (subnets). Should be enough for every human on earth for sure.
- kaliszad 5y ago
  It is something like one /48 for each second square meter of land on Earth or something in that ballpark. It definitely can be exhausted, but that is only because we more or less use the last 64 bit for grouping hosts, autoconfiguration etc. which doesn't have to be the case everywhere (e.g. container hosts, where giving each container or even a container host a /80 can be more than enough).
pezezin 5y ago
That legacy IPv4 already exists, it's ::ffff:0:0/96