[lwip-devel] [bug #53803] nd6_cleanup_netif should set the auto-configured address to invalid

[David van Moolenbroek]

Follow-up Comment #4, bug #53803 (project lwip):

Sure! This is a tricky area though: I was unable to find any information on
what exactly should happen in a link-down situation, and my own (MINIX) side
of the code has a massive "TODO" there. I don't think I ever checked what
other operating systems were doing, either. But I can provide some thoughts -
first on the policy, then something about the mechanism.

As for the policy (i.e., is this a good idea at all), I do not think the
argument holds that removal of the (on-link) prefix should also imply removal
of the address: the argument made sense for the lwIP code back then, because
lwIP was conflating on-link prefixes and address auto-configuration at the
time. That is part of what my change corrected. These days (and in accordance
with the RFC), the presence or absence of an on-link prefix says nothing about
the address, and it would definitely be wrong to retire an auto-configured
address as soon as the matching on-link prefix expires.

However, there is indeed an argument to be made that link disconnection should
remove any information for the previously attached network, because that
information can no longer be relied upon. That would then include not only
on-link prefixes, but also auto-configured addresses. The effect will likely
be that it takes a bit more time for the node to regain connectivity though,
because it has to reobtain an IP address even after a very brief link
interruption - losing any TCP connections and whatnot as a side effect.

Alternatively, and at the very minimum (so there is definitely something to
fix here either way), upon link-down the auto-configured addresses should be
moved back from PREFERRED/DEPRECATED to TENTATIVE, because even if the link is
reconnected to the same network, another node may have appeared with the same
address during the downtime. This is in fact what the MINIX code does, because
it is required by dhcpcd. I did not put a lot of thought into that beyond
implementing that part, and I don't think I realized that it is in fact lwIP
that should (always) put the addresses back to TENTATIVE state in that case.

Then again, that alternative does not resolve the poster's original problem,
which basically involves a scenario of reconnecting to another network (i.e.,
one where the previously auto-configured address is not routable). It is worth
pointing out that as per my change, this situation will eventually correct
itself, because the address will now eventually time out. However, that may
take a long time - much longer than reobtaining an IP address. Increasing the
number of addresses per netif (from 3 to 4 in this case) would help the
situation, because then the new address can be assigned next to the old one,
for as long as the old address is still around. However, I don't think it
would stop the old address from getting selected as a source address while it
is still around.

I also do not see any way to combine the best of both worlds here, at least
without keeping extra state - state that indicates that an address may still
be valid but hasn't been confirmed by announcements ever since the last
link-up event, or something similar. That gets messy quickly, and is probably
overkill.

Adding it all up, I am leaning toward agreeing that removal of the addresses
is the right thing to do in this case, but it may have a negative impact in
some situations, especially with poor links that drop out every once in a
while. I don't know if changing attached networks is a common scenario for the
situations in which lwIP is deployed. As always, it would be tempting to turn
this into a configurable option and let the user decide.

If address removal is indeed a good idea, that then leaves the mechanism,
because the suggested patch no longer works with the current code at all.
Instead, the code should basically follow the same logic as the lifetime-based
expiry code: for all IPv6 addresses assigned to the netif, if the address is
not invalid and not static, set the valid and preferred lifetimes to zero and
mark the address state as INVALID.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?53803>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/