Re: bin/57957: dhcpcd fails to unconfigure addresses from released lease

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/57957; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/57957: dhcpcd fails to unconfigure addresses from released lease
Date: Sun, 25 Feb 2024 16:12:24 +0700

 I used to see this quite frequently - it happened when (for whatever
 reason) there was no network connectivity at the time the router was
 trying to alter the IPv6 addr (ISPs that don't like any customers to
 have a stable address for very long!)
 
 If the RA (or sequence of RAs perhaps) indicating that the old address
 was deprecated were missed, the old addr would simply hang around
 forever, with the effects as stated in the PR.   A new one would appear,
 but wouldn't be used.
 
 Whatever is managing RAs (dhcpcd now, I suppose) should be looking for
 all prefixes being announced in all RAs, and if long enough passes with
 a prefix simply missing from the announcements, then drop it.
 
 Of course, it needs to know which addresses (and corresponding prefix)
 were assigned this way, not delete addresses which might have been
 statically added (someone typing "ifconfig xx0 ..."), and that needs
 to happen even if dhcpcd was restarted in the meantime (this was one of
 the advantages of kernel processing - if the kernel restarts, all old
 addrs (and everything else) simply vanish - dhcpcd restarting doesn't
 make that happen, and nor should it).
 
 Note that simply missing from one RA is not enough - there might be
 more than one router on a LAN advertising different prefixes, or a
 router might not announce everything in every RA.
 
 kre
 
 ps: What I used to do when this happened was to use ifconfig and simply
 remove the bad address, after which it all recovers - but naturally that
 means having a method to access the system, distinct from the badly
 configured network interface.