4 ms·
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 deca
by 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 agoYou'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 agoBackwards 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.