Peter Memishian wrote:
> Seb/Erik,
>
> In Nevada, when an IP interface's link-local address goes down, in.ndpd
> prints:
>
> Interface net0 has been removed from kernel. in.ndpd will no longer use it
>
> ... 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. BTW:
Does the DHCPv6 client do the same thing?
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.
Erik
> I ask because if I could make this change, then I wouldn't need to add the
> message-passing interface between ifconfig and in.ndpd to convince it to
> stop managing the soon-to-be-underlying interfaces: ifconfig *already*
> brings down the link-local as part of preparing for an IP interface to
> join a group, so things would work cleanly. So, is there an issue with
> this approach?
>
> PS. As part of researching this I found a bunch more old IPMP-related code
> in in.ndpd`check_if_removed() that can be deleted with Clearview IPMP.
>
> Thanks,
