Why would IPv6 interfere with pinging an IPv4 address?
I ran into an odd (to me, at least) situation at a client's yesterday and was hoping to understand what was going on. The client reported that she lost her WiFi internet connection in Windows 10. I confirmed that it was successfully connecting to the WiFi router, but I was unsuccessful at pinging the default gateway's IPv4 address. I confirmed that all addresses were correct.
The client reported that this had been working for months then started having intermittent problems since the ISP replaced the modem/router.
I made a wired connection and it worked properly.
I was able to resolve the problem by disabling IPv6, but I don't understand why that would affect pinging an IPv4 address (e.g. ping 10.0.0.1). I would have expected that to use IPv4.
I didn't look for she preference about using IPv4 over IPv6. I suspect that would have also resolved the issue.
If anyone can help educate me about what happened, I'd appreciate it greatly!
The client reported that this had been working for months then started having intermittent problems since the ISP replaced the modem/router.
I made a wired connection and it worked properly.
I was able to resolve the problem by disabling IPv6, but I don't understand why that would affect pinging an IPv4 address (e.g. ping 10.0.0.1). I would have expected that to use IPv4.
I didn't look for she preference about using IPv4 over IPv6. I suspect that would have also resolved the issue.
If anyone can help educate me about what happened, I'd appreciate it greatly!
kevinhsieh
The newer ISP gear will often hand out IPv6, which is then preferred by the client. Not sure why pinging by IPv4 was broken though.
You should be able to ping the gateway even if IPV6 is enabled, unless your router is configured in a way to prioritize IPV6 over IPV4. That's why when you're disabling IPV6 it's working. Check your router configuration,
IPv6 has no interaction with IPv4 and shouldn't have any affect on IPv4 operations (for sure for pinging IPv4 address).
IPv4 function correctly after IPv6 is disabled is either bug related or unrelated to original issue.
IPv4 function correctly after IPv6 is disabled is either bug related or unrelated to original issue.
I have encountered multiple situations where I have had to disable IPv6 in order to get a client's network to function after installing a new router.
I cannot offer an explanation, but it is certainly not all that uncommon.
As Predrag notes, this should not happen, but in my experience it does sometimes.
Try disabling IPv6 on the router, and see if that fixes it.
If it does, I would love to understand why that is too!
Thanks,
Alan.
I cannot offer an explanation, but it is certainly not all that uncommon.
As Predrag notes, this should not happen, but in my experience it does sometimes.
Try disabling IPv6 on the router, and see if that fixes it.
If it does, I would love to understand why that is too!
Thanks,
Alan.
use the -4 parameter for ping This will force using ipv4
i.e.
png 10.0.0.1 -4
i.e.
png 10.0.0.1 -4
ipv4 and ipv6 are separated and can live together very well. (i have used a dual stack for about 7 years now without major issues.)
ipv4 & ipv6 only share the first few bytes of any IP packet. up to the version number which is surprisingly 4 for ipv4 and 6 for ipv6
From then on the packets start to differ in layout and handling.
IPv6 is prioritized over IPv4, so if you request something by name AAAA records are requested and on failure A is tried next (solving IPv4 only destinations)
if an IP address is used it can be inferred from the address it is IPv4 or ipv6. ping to any IPv4 address should take IPv4 it can be forced with a flag like David mentions. -4 for IPv4, -6 for IPv6.
Did you check routing? netstat -rn4 and netstat -rn6
Doest the default gateway answer to ping anyway?
There is no situation where an IPv4 connection is converted into IPv6 any intermediate hardware. (NAT46 / NAT64 fails on too many levels to be useful).
ipv4 & ipv6 only share the first few bytes of any IP packet. up to the version number which is surprisingly 4 for ipv4 and 6 for ipv6
From then on the packets start to differ in layout and handling.
IPv6 is prioritized over IPv4, so if you request something by name AAAA records are requested and on failure A is tried next (solving IPv4 only destinations)
if an IP address is used it can be inferred from the address it is IPv4 or ipv6. ping to any IPv4 address should take IPv4 it can be forced with a flag like David mentions. -4 for IPv4, -6 for IPv6.
Did you check routing? netstat -rn4 and netstat -rn6
Doest the default gateway answer to ping anyway?
There is no situation where an IPv4 connection is converted into IPv6 any intermediate hardware. (NAT46 / NAT64 fails on too many levels to be useful).
ASKER
@Elie
I don't understand how this would be a router issue. If my client sends an IPv4 ping packet, shouldn't the router respond with an IPv4 packet?
I don't understand how this would be a router issue. If my client sends an IPv4 ping packet, shouldn't the router respond with an IPv4 packet?
ASKER
@David
Are you suggesting that if I type: ping 192.168.1.1 it might use IPv6? That certainly could explain the issue.
I thought/assumed that the -4 was to be used when one was pinging a name, not a specific IPv4 address.
Are you suggesting that if I type: ping 192.168.1.1 it might use IPv6? That certainly could explain the issue.
I thought/assumed that the -4 was to be used when one was pinging a name, not a specific IPv4 address.
ASKER
@noci
Your comments are consistent with what I knew/assumed/presumed. That's why I'm confused why a command such as ping 10.0.0.1 would be impacted by whether or not IPv6 was enabled.
"Doest the default gateway answer to ping anyway? "
Yes. When IPv6 is disabled, the problem goes away.
If the issue were on my network, I'd take a look with wireshark to see what's going on. It's not and not practical to do so at the client.
Your comments are consistent with what I knew/assumed/presumed. That's why I'm confused why a command such as ping 10.0.0.1 would be impacted by whether or not IPv6 was enabled.
"Doest the default gateway answer to ping anyway? "
Yes. When IPv6 is disabled, the problem goes away.
If the issue were on my network, I'd take a look with wireshark to see what's going on. It's not and not practical to do so at the client.
The only explanation that I can think of for ping to gateway fails when IPv6 is on, is that host is not finding AAAA record for 10.0.0.1 when IPv6 DNS try to resolve 10.0.0.1 as it is FQDN.
ASKER
@Predrag:
Are you suggesting that the workstation is treating 10.0.0.1 as a name and not an IP address? I can see how that would fail name resolution, but not why it would try to resolve it as a name in the first place.
Are you suggesting that the workstation is treating 10.0.0.1 as a name and not an IP address? I can see how that would fail name resolution, but not why it would try to resolve it as a name in the first place.
That's the only reasonable explanation that I can think of beside bug. IPv6 has different format and if 10.0.0.1 is treated as IPv4 address it would would make no difference if IPv6 is disabled or not.
Handling the IPv4 address as a host name would be strange, unless there is a . too many. (1 or 2 dot means the missing numbers in between are 0.
ie. ping 1.1 => ping 1.0.0.1)
ie. ping 1.1 => ping 1.0.0.1)
ASKER
@noci
While I can't say I'm above making such a mistake (extra dots), I don't think it was the case here. I tested a number of times both before and after disabling IPv6 and the first IPv6 test was a repeat of the last IPv4 test by using the up arrow to repeat the command.
While I can't say I'm above making such a mistake (extra dots), I don't think it was the case here. I tested a number of times both before and after disabling IPv6 and the first IPv6 test was a repeat of the last IPv4 test by using the up arrow to repeat the command.
ASKER
Closing this out. Thank you all for your suggestions.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.