IPv6 on lo never leaves 'tentative' state if configured with prefixlen 128. Steps to reproduce. # ifconfig lo8 create # ifconfig lo8 up # ifconfig lo8 inet6 fc00::ff prefixlen 128 # ifconfig lo8 lo8: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> inet6 fc00::ff prefixlen 128 tentative nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> lo8 ipv6 stays 'tentative' stays forever and never become ping-able. "Workaround" is to apply any other prefixlen, e.g. /127 Fix: "Workaround" is to apply any other prefixlen, e.g. /127 How-To-Repeat: # ifconfig lo8 create # ifconfig lo8 up # ifconfig lo8 inet6 fc00::ff prefixlen 128 # ifconfig lo8 lo8: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> inet6 fc00::ff prefixlen 128 tentative nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> # ping fc00::ff
Hello, Actually the problem is in your configuration. As you may see, you have IFDISABLED flag set. When you are configuring /127 prefix, the system does install route on that prefix and automatically clears IFDISABLED flag. When you are configuring /128 prefix, the system won't install route and thus IFDISABLED flag still here. With IFDISABLED flag the system won't do DAD and tentative flag will never cleared. -- WBR, Andrey V. Elsukov
I'm not setting IFDISABLED flag as you see from output below. Moreover the same set of commands doesn't dot put interface into IFDISABLED sate on FreeBSD 7.x, 8.x, 9.x Again, if I set IPv4 /32 it works as well. Thus this /128 case is a clear regression.
All interfaces have IFDISABLED flag if you have not configured IPv6 for them. -- WBR, Andrey V. Elsukov
I do configure IPv6, output clearly says that, and more specifically I configure it with /128. Let me show again again: case A, getting 'tentative' # ifconfig lo8 create # ifconfig lo8 up # ifconfig lo8 inet6 fc00::ff prefixlen 128 <- configuring IPv6 address with /128 prefix case B, all good, NO 'tentative' # ifconfig lo8 create # ifconfig lo8 up # ifconfig lo8 inet6 fc00::ff prefixlen 127 <- configuring IPv6 address with /127 prefix On FreeBSD 7.x, 8.x, 9.x case A works, while on 10.x interface is stuck in `tentative` permanently.
I described why this works as you see in the first message. There are number of configuration variables related to IPv6 configuration. I.e. ipv6_enable, ipv6_activate_all_interfaces, ifconfig_xxx_ipv6. These variables controls behavior of the system when new interface will appears. You can read /etc/network.subr and you will see that presence of IFDISABLED flag depends from these variables. -- WBR, Andrey V. Elsukov
Basically behavior is is like that /128 mask: ipv6_activate_all_interfaces="YES" && /128 -> OK NO ipv6_activate_all_interfaces && /128 -> *tentative* /127 mask: ipv6_activate_all_interfaces="YES" && /127 -> OK NO ipv6_activate_all_interfaces && /127 -> *OK* I find that behavior is inconsistent, mask of /128 has no any magic meaning.
Responsible Changed From-To: freebsd-bugs->freebsd-net assign.
I was pulling my hair out all day trying to figure out why my jails weren't working with IPv6, and finally figured out they couldn't use their assigned IP addresses. A few hours later I noticed the "tentative" in ifconfig and eventually stumbled on this PR. IMO, the lack of "ipv6_activate_all_interfaces" should have no effect on the status of the interfaces when they're explicitly configured in jail settings.
Take.
Created attachment 148784 [details] A patch to automatically clear ifdisabled flag even in /128 case Please try this patch.
Thanks for the patch! It worked perfectly for me. Please commit to 10-STABLE and CURRENT.
A commit references this bug: Author: hrs Date: Sun Nov 2 21:58:32 UTC 2014 New revision: 273992 URL: https://svnweb.freebsd.org/changeset/base/273992 Log: Fix a bug which prevented ND6_IFF_IFDISABLED flag from clearing when the newly-added IPv6 address was /128. PR: 188032 Changes: head/sys/netinet6/in6.c
Committed in r273992.
Close PRs that have had a corresponding fix committed.
Still needs MFC.
There is a commit referencing this PR, but it's still not closed and has been inactive for some time. Closing the PR as fixed but feel free to re-open it if the issue hasn't been completely resolved. Thanks