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

[Roy Marples <roy%marples.name@localhost>]

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

From: Roy Marples <roy%marples.name@localhost>
To: "gnats-bugs" <gnats-bugs%netbsd.org@localhost>
Cc: "Robert Elz" <kre%munnari.OZ.AU@localhost>, "gnats-admin" <gnats-admin%netbsd.org@localhost>,
	"netbsd-bugs" <netbsd-bugs%netbsd.org@localhost>,
	"campbell+netbsd" <campbell+netbsd%mumble.net@localhost>
Subject: Re: bin/57957: dhcpcd fails to unconfigure addresses from released
 lease
Date: Sun, 25 Feb 2024 12:18:03 +0000

  ---- On Sun, 25 Feb 2024 09:15:02 +0000  Robert Elz  wrote --- 
  >  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.
  
 If dhcpcd received an address via DHCPv6 or RA with a lifetime of zero then it is removed from the interface.
 Otherwise dhcpcd leaves it alone and the address will naturally expire.
 This behaviour is pretty well documented in then RFCs.
 
 So the only issue left is one of source address selection.
 There is a bug where if the source address is the only thing to change on the route then the kernel route isn't updated with the new source address.
 This is being tracked upstream here:
 https://github.com/NetworkConfiguration/dhcpcd/issues/300
 
 Roy