On Sat, 2008-11-08 at 03:20 -0500, 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?
The rationale behind the existing behavior is that the protocol gracefully handles the removal of addresses when their associated prefixes become invalid, and the inability of in.ndpd to send out periodic RSs would eventually lead to that condition. There is thus no explicit need in the current code to do anything special with auto-configured addresses when a link-local address goes away. To correct your metaphor, the addresses aren't really "flapping in the breeze", but rather they're "on death row". > Could it instead just prefix_delete() all the PR_AUTO > prefixes, and recreate them if the link-local comes back up? It could do that, and I personally don't think that this would be a particularly bad thing. It might even be a generally useful mechanism that could be documented in the in.ndpd man page. It's actually too bad that there isn't an administrative command-line tool (with associated API of course) for controlling and observing stateless address auto-configuration and router discovery, because if there were, that might be one of its functions. > 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? I don't have 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. Okay, send that along and I'll review it. -Seb
