> > 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.
That makes sense. > To correct your metaphor, the addresses aren't really "flapping in the > breeze", but rather they're "on death row". OK, so in.ndpd's message is misleading in that case, in that it will clean those up eventually, even in.ndpd says it's done with net0. > > 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. Yes, I think that'd be useful. However, for Clearview IPMP I'd like to keep the changes in this area as minimal as possible. > > 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. Cool, let me try this out and get back to you. -- meem
