4 ms·

IPv6 is large enough to represent the whole IPv4 range. Multiple times. Initially (at the very beginning) it was possible to connect to IPv4 address using IPv6

by drran 5y ago

IPv6 is large enough to represent the whole IPv4 range. Multiple times. Initially (at the very beginning) it was possible to connect to IPv4 address using IPv6 socket. They were called «IPv4-Compatible IPv6 Address»[0]. For example, I can ping both ipv4 and ipv6 addresses using ping: $ ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms $ ping ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.044 ms However, this feature allowed to bypass NAT and connect to IPv4 hosts directly via IPv6, so it deprecated. (I skipped names to avoid scapegoating). $ ping6 ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.043 ms $ ping6 127.0.0.1 ping6: 127.0.0.1: Address family for hostname not supported It's not a technical issue, see above: it's possible to serve both protocols at the same time. It worked for a brief period. It's purely political decision: backward support for IPv4 in IPv6 was disabled because some people are thinking that such behavior is dangerous. [0]: https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.1 https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5....

chungy 5y ago
That's... really not how any of it works, and the ping examples are a red herring. IPv4-compatible IPv6 addresses basically allows applications to connect to IPv4 hosts using just a single IPv6-compatible network stack. The operating system kernel handles the translation to and from IPv4 native. There's no way it can "bypass NAT" -- that doesn't even make sense, NAT causes the hosts behind a network to all have the same external network, the exact same incoming rules would apply as they always have. As for ping: back in the 1990s and 2000s, ping only understood IPv4 addresses and an independent command "ping6" was made to work on IPv6. In the mean time, regular ping understand both protocols just fine and you don't need a separate one. Modern Linux distros don't even have a "ping6" anymore.
- drran 5y ago
  Ping is just example to illustrate that the problem is not technical in a way which makes it easy to understand. I'm talking about this issue for more than decade (at national level), so I nailed some patterns. Yes, IPv4 packets and address range are too small to support IPv6, but IPv6 can encapsulate them with room to spare, so IPv6 network can address and handle IPv4 networks and hosts directly. However, this may enable two disconnected IPv4 networks to communicate via IPv6, if they are both announced at ipv6 network. For example, my notebook is behind IPv4 NAT, but bots were able to scan and try to log into my SSH via IPv6 (miredo). Theoretically, when IPv6 will support both IPv6 and IPv4, I can expose my internal IPv4 network via IPv6, which may create security risk, same as for IPv6 native network without NAT. This is the key problem: people don't want to expose internal networks to the public, so the feature was cut with hope that everyone will switch to IPv6 and this will no longer be a problem. In 2004, I was lead of OPS team, so I spent some time trying to invent a way to switch our internal network to IPv6, when it will hit mainstream, and found that seamless transition is not possible at all: IPv6 requires switch, because backward compatibility is disabled, just because a corporation asked for that.
  - chungy 5y ago
    You're still confusing unrelated topics in the field. > However, this may enable two disconnected IPv4 networks to communicate via IPv6, if they are both announced at ipv6 network. If they share an IPv6 network, they can communicate over IPv6. If they are truly disconnected from each other with IPv4, they cannot in any way communicate over IPv4, this includes using, for example, "::ffff:192.168.1.1" as an address. > For example, my notebook is behind IPv4 NAT, but bots were able to scan and try to log into my SSH via IPv6 (miredo). This has nothing to do with IPv4 encapsulating in an IPv6 stack. Instead, you've configured your host to have a public IPv6 address by way of using proxy servers to provide bidirectional communication. If you don't want this, stop using miredo. > people don't want to expose internal networks to the public Well, stop doing it. Stop running miredo if you don't want that behavior. Install firewalls and policies to block incoming traffic. IPv6 doesn't magically transform your NAT'd IPv4 network into a public free-for-all space. You really have to work at opening up that possibility yourself (such as by installing/using miredo). IPv6 cannot in any way bypass a NAT and reach IPv4 hosts directly behind them. Encapsulated IPv4 packets in IPv6 are translated at some point along the chain (typically the computer running the application using an ::ffff:0.0.0.0/96 address) into the native IPv4 networking world where the packets are handled as if the application used an IPv4 address directly. The encapsulated addresses are primarily a convenience factor, nothing else, and no security implications. (I sort of think you are also thinking of 6to4 and/or NAT64 in this discussion, which can punch a hole through your NAT in the way you are describing. If you don't want this, don't do this!)
  - Dagger2 5y ago
    Backwards compatibility isn't "disabled" in v6. There are plenty of backwards compatibility methods available. You can do a seamless transition by deploying v6 and then undeploying v4 once you no longer need it. You can speed the second part up by using NAT64+DNS64.

by drran 5y ago

chungy 5y ago

That's... really not how any of it works, and the ping examples are a red herring. IPv4-compatible IPv6 addresses basically allows applications to connect to IPv4 hosts using just a single IPv6-compatible network stack. The operating system kernel handles the translation to and from IPv4 native. There's no way it can "bypass NAT" -- that doesn't even make sense, NAT causes the hosts behind a network to all have the same external network, the exact same incoming rules would apply as they always have. As for ping: back in the 1990s and 2000s, ping only understood IPv4 addresses and an independent command "ping6" was made to work on IPv6. In the mean time, regular ping understand both protocols just fine and you don't need a separate one. Modern Linux distros don't even have a "ping6" anymore.

drran 5y ago
Ping is just example to illustrate that the problem is not technical in a way which makes it easy to understand. I'm talking about this issue for more than decade (at national level), so I nailed some patterns. Yes, IPv4 packets and address range are too small to support IPv6, but IPv6 can encapsulate them with room to spare, so IPv6 network can address and handle IPv4 networks and hosts directly. However, this may enable two disconnected IPv4 networks to communicate via IPv6, if they are both announced at ipv6 network. For example, my notebook is behind IPv4 NAT, but bots were able to scan and try to log into my SSH via IPv6 (miredo). Theoretically, when IPv6 will support both IPv6 and IPv4, I can expose my internal IPv4 network via IPv6, which may create security risk, same as for IPv6 native network without NAT. This is the key problem: people don't want to expose internal networks to the public, so the feature was cut with hope that everyone will switch to IPv6 and this will no longer be a problem. In 2004, I was lead of OPS team, so I spent some time trying to invent a way to switch our internal network to IPv6, when it will hit mainstream, and found that seamless transition is not possible at all: IPv6 requires switch, because backward compatibility is disabled, just because a corporation asked for that.
- chungy 5y ago
  You're still confusing unrelated topics in the field. > However, this may enable two disconnected IPv4 networks to communicate via IPv6, if they are both announced at ipv6 network. If they share an IPv6 network, they can communicate over IPv6. If they are truly disconnected from each other with IPv4, they cannot in any way communicate over IPv4, this includes using, for example, "::ffff:192.168.1.1" as an address. > For example, my notebook is behind IPv4 NAT, but bots were able to scan and try to log into my SSH via IPv6 (miredo). This has nothing to do with IPv4 encapsulating in an IPv6 stack. Instead, you've configured your host to have a public IPv6 address by way of using proxy servers to provide bidirectional communication. If you don't want this, stop using miredo. > people don't want to expose internal networks to the public Well, stop doing it. Stop running miredo if you don't want that behavior. Install firewalls and policies to block incoming traffic. IPv6 doesn't magically transform your NAT'd IPv4 network into a public free-for-all space. You really have to work at opening up that possibility yourself (such as by installing/using miredo). IPv6 cannot in any way bypass a NAT and reach IPv4 hosts directly behind them. Encapsulated IPv4 packets in IPv6 are translated at some point along the chain (typically the computer running the application using an ::ffff:0.0.0.0/96 address) into the native IPv4 networking world where the packets are handled as if the application used an IPv4 address directly. The encapsulated addresses are primarily a convenience factor, nothing else, and no security implications. (I sort of think you are also thinking of 6to4 and/or NAT64 in this discussion, which can punch a hole through your NAT in the way you are describing. If you don't want this, don't do this!)
- Dagger2 5y ago
  Backwards compatibility isn't "disabled" in v6. There are plenty of backwards compatibility methods available. You can do a seamless transition by deploying v6 and then undeploying v4 once you no longer need it. You can speed the second part up by using NAT64+DNS64.