FreeBSD 13.2-RELEASE / IPV6 disable bug

MrX86

MrX86

Bug:
FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597


(IPV6 disable)

rc.conf:
ip6addrctl_enable="NO"
ip6addrctl_policy="ipv4_prefer"
ipv6_activate_all_interfaces="NO"
ipv6_network_interfaces="none"


after this:

ping www.xxxxx.xx

UDP error
 
does anyone have info why this is so

how do i completely disable the v6 section for 13.2
correctly ?
 
No, not a bug. Ping works very differently for IPv6 and IPv4, traditionally there were two utilities ping6 and ping. In 13, they were integrated into the single ping tool, and this defaults to IPv6 operation. The address policy only works for software resolving a name without specifying an address family, which ping can't do as operation differs depending on the protocol. So, with IPv6 disabled on your network interfaces, it just can't reach any host in IPv6 mode. The only way for ping to automatically fall back to IPv4 mode would be if the name doesn't resolve to any IPv6 address.

In short, just use ping -4.
 
zirias@ said:
No, not a bug. Ping works very differently for IPv6 and IPv4, traditionally there were two utilities ping6 and ping. In 13, they were integrated into the single ping tool, and this defaults to IPv6 operation. The address policy only works for software resolving a name without specifying an address family, which ping can't do as operation differs depending on the protocol. So, with IPv6 disabled on your network interfaces, it just can't reach any host in IPv6 mode. The only way for ping to automatically fall back to IPv4 mode would be if the name doesn't resolve to any IPv6 address.

In short, just use ping -4.
Click to expand...
Top explanation

Too bad that again and again things are changed
Which for years were never an issue
 
MrX86 said:
Too bad that again and again things are changed
Which for years were never an issue
Click to expand...
Well, needing a separate utility for IPv6 started to feel a little weird as IPv6 finally became the de-facto standard on the internet and IPv4 more and more a second class citizen. I mean, many ISPs don't even offer private customers "real" IPv4 any more, just a tunneled variant with CGNAT for backwards compatibility.

On the other hand, there are still die-hard IPv4-only subnets, so you really need both for now. But you also might want to reconsider disabling IPv6 in 2023. The number of hosts on the internet without IPv4 is ever increasing....
 
zirias@ said:
Well, needing a separate utility for IPv6 started to feel a little weird as IPv6 finally became the de-facto standard on the internet and IPv4 more and more a second class citizen. I mean, many ISPs don't even offer private customers "real" IPv4 any more, just a tunneled variant with CGNAT for backwards compatibility.

On the other hand, there are still die-hard IPv4-only subnets, so you really need both for now. But you also might want to reconsider disabling IPv6 in 2023. The number of hosts on the internet without IPv4 is ever increasing....
Click to expand...
You're right.
 
MrX86 said:
Top explanation
Click to expand...
And unfortunately not entirely correct it seems: I just tested it from one of my jails that doesn't have IPv6 connectivity. Although IPv6 in that jail isn't even disabled on the interfaces, ping(8) still managed to immediately fall back to IPv4.

Now I can only speculate, I also don't have any addrctl policy configured – my guess is that ping will receive ICMP messages telling it that IPv6 won't work and in this case immediately try IPv4. Some firewall might interfere with that mechanism for example.

But still, most likely not a bug but something related to your networking environment.

Looking at your original posting again:
MrX86 said:
UDP error
Click to expand...
This seems more than strange. ping(8) should only ever use ICMP, never UDP. Are you sure you copied that message correctly?
 
You must log in or register to reply here.
Back
Top