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: "Taylor R Campbell" <riastradh%NetBSD.org@localhost>
Cc: "Robert Elz" <kre%munnari.OZ.AU@localhost>, "gnats-bugs" <gnats-bugs%NetBSD.org@localhost>,
	"roy" <roy%NetBSD.org@localhost>, "gnats-admin" <gnats-admin%NetBSD.org@localhost>,
	"netbsd-bugs" <netbsd-bugs%NetBSD.org@localhost>
Subject: Re: bin/57957: dhcpcd fails to unconfigure addresses from released
 lease
Date: Sun, 25 Feb 2024 16:28:33 +0000

  ---- On Sun, 25 Feb 2024 15:13:03 +0000  Taylor R Campbell  wrote --- 
  > > Date: Sun, 25 Feb 2024 15:05:01 +0000 (UTC)
  > > From: Robert Elz kre%munnari.OZ.AU@localhost>
  > > 
  > > But that would still be wrong, the old addresses should expire,
  > > but weren't (and apparently didn't for Taylor either).
  > 
  > Just to clarify: the issue I observed is that the old DHCPv6-assigned
  > addresses weren't removed.
 
 Why should they be? They obey the same rules as RA addresses in that removal is either manual or a zero lifetime is emitted.
 Now IA options can include a  status code such as NotOnLink, but there is no indication in the RFC that any existing address should be removed.
 Infact it's recommendation to enter discovery mode and find a new DHCPv6 server.
 
 Is the lifetime of the address continously decreasing or does it ever increase?
 
 > (and kept getting used as default source
  > addresses).
 
 I find this statement odd because DHCPv6 addresses are not tied to any route.
 Infact there is zero routing in DHCPv6 because RA covers it nicely.
 
 >  The SLAAC addresses with the old prefix, in contrast, did
 > get removed and replaced by SLAAC addresses with the new prefix.
  
 The error in dhcpcd is that when a prefix derived route changes it's address the source address in the route is not changed.
 But I don't think this is what you are seeing.