> > ... but then it proceeds to leave any ADDRCONF'd addresses flapping in the
> > breeze on the IP interface. Since in.ndpd has stopped management of those
> > addresses (via the message above and via phyint_cleanup()), and indeed no
> > longer has a working link-local to manage them with, does it make sense to
> > keep them around? Could it instead just prefix_delete() all the PR_AUTO
> > prefixes, and recreate them if the link-local comes back up?
>
> Assuming in.ndpd isn't fooled by incorrect routing socket messages i.e.,
> that it is robust against the internal ipif_down+ipif_up changes that
> the kernel does, then I don't see a problem with taking the link-local
> address going down as an indication that in.ndpd should clean up.
I don't see how in.ndpd has any real way to distinguish between these two
cases, though it will recover. (As an aside, Jim pointed out to me that
in certain cases, applications may actually be expecting address down/up
transitions as part of address-related configuration operations -- I
haven't looked at how other Unices model e.g. SIOCSIFNETMASK operations.)
> BTW: Does the DHCPv6 client do the same thing?
Not that I can see. (It does check some other things, such as ensuring
that the link-local address is the same one that it used when it initially
acquired the lease.)
As Seb mentioned, a core issue is that (unlike e.g DHCPv4) there's no
explicit way to control in.ndpd once it's running. Ideally, I think it'd
make sense to add that mechanism, and then we could go back to letting
ADDRCONF'd addresses time out unless something explicitly requested that
they be removed. But I'm uncomfortable with adding that mechanism as part
of the Clearview IPMP work if the suggestion in this thread is sufficient
to address the issue. If it's not, then I can add the mechanism.
> One thing to look out for are interfaces that don't have a link-local
> address. I think 6to4 falls in that category. Need to make sure we don't
> regress the behavior for such interfaces.
>From a closer inspection of the code, we go through this code in
check_if_removed() whenever the physical (zeroth) address is brought down
(which -- based on what you state above -- may not be a link-local):
if (!(pi->pi_kernel_state & PI_PRESENT) &&
(pi->pi_state & PI_PRESENT)) {
logmsg(LOG_ERR, "Interface %s has been removed from kernel. "
"in.ndpd will no longer use it\n", pi->pi_name);
/*
* Clear state so that should the phyint reappear
* we will start with initial advertisements or
* solicitations.
*/
phyint_cleanup(pi);
}
My proposal was to expand the above to also delete ADDRCONF'd prefixes
on that phyint.
--
meem
