lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #53803] nd6_cleanup_netif should set the auto-configur


From: David van Moolenbroek
Subject: [lwip-devel] [bug #53803] nd6_cleanup_netif should set the auto-configured address to invalid
Date: Thu, 14 Jun 2018 15:33:29 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

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

When the link stays up, then the solution for your scenario is simple: the
router should announce the prefix with zero lifetimes. That is covered
explicitly in RFC 4861 Section 12 in general, although for addresses it is not
exactly that simple: such announcements will not cause any existing address to
be removed immediately (as per Sec. 5.5.3(e) of RFC 4862) - at most they will
be changed from PREFERRED to DEPRECATED state right away. Then, any newly
announced prefix may cause the addition of a new address next to that address,
and that address will end up with the PREFERRED state. As a result, the old
address will remain usable on the host for a while (e.g. for existing TCP
connections), while the new address will be preferred for source address
selection. I believe it is generally best to have at least enough IPv6 address
slots for one preferred dynamic (SLAAC) address and one deprecated one,
because such situations are normal and any host system should be able to deal
with them.

In fact, we could use a highly similar approach to resolve the link-down
issue: upon a link-down event, set the address state to TENTATIVE *and* set
the address's preferred (but NOT its valid) lifetime to zero. The result will
be that after link-up, it will go from TENTATIVE to DEPRECATED in the absence
of new router announcements for the old prefix. Then, the result will be the
same as above: the old address will not be selected as source address if there
is also a PREFERRED address that was assigned based on new router
announcements instead, and at the same time, currently open TCP connections
would continue to use the DEPRECATED address (perhaps fruitlessly, perhaps
not, depending on the new situation). Again, the only requirement would be to
have at least two dynamic IPv6 address slots available, which is probably even
reasonable to recommend in opt.h.

That is just an idea though, and I certainly won't claim that I have thought
of everything here.. :) In any case: indeed, any such new logic should be
invoked on link-down events, not (just) on changes of the netif's
administrative state. I suppose that similar considerations apply to both
those cases, and so perhaps nd6_cleanup_netif() should also be called on
link-down..

But yes, checking other operating systems would definitely be a good start.
I'll see what I can contribute there, but that is going to take some time..

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]