When an on-link prefix becomes detached (i.e. the router stops advertising it), the router should first send a final Router Advertisement withdrawing the prefix by setting its lifetime to zero, and then begin advertising the new prefix with its normal lifetime. This case is supported correctly by FreeBSD: temporary addresses are no longer generated for a prefix that has been properly withdrawn.

If the network equipment does not handle the transition correctly, however, we can end up in the situation described in PR 298533. The same situation can occur when an interface is physically moved from one IPv6 network to another, for example by unplugging the cable and connecting it to a different network. In that case, the host may continue to consider the old prefix valid because it never received a proper withdrawal.

This can result in multiple prefixes being present on the interface simultaneously. Stable and temporary addresses may then exist for both prefixes, and temporary addresses may continue to be regenerated for both of them. From my observations, temporary addresses are regenerated for only two prefixes in this situation, although I have not investigated the relevant code in detail and this is based only on a few experiments.

After running some additional tests and taking the above behavior into consideration, I do not see any significant change in the handling of IPv6 prefix deprecation after applying this patch. In particular, the behavior I observe appears to be the same for a properly withdrawn prefix and does not seem to address the case where an interface is moved to another IPv6 network without the old prefix being explicitly withdrawn.

For a reason unknown to me, perhaps a temporary failure of Bugzilla, I can't comment on the PR directly, so let me note it here.

I cannot reproduce this failure described in bug 298533 when the network equipment is configured correctly and properly withdraws the old prefix. If the problem occurs after physically moving the interface to a different IPv6 network, the interface should be reconfigured as part of that network change. Without such reconfiguration or a proper prefix withdrawal from the router, I don't think this particular scenario can reasonably be considered an operating system failure.

In D60051#1378243, @zarychtam_plan-b.pwste.edu.pl wrote:

For a reason unknown to me, perhaps a temporary failure of Bugzilla, I can't comment on the PR directly, so let me note it here.

I cannot reproduce this failure described in bug 298533 when the network equipment is configured correctly and properly withdraws the old prefix. If the problem occurs after physically moving the interface to a different IPv6 network, the interface should be reconfigured as part of that network change. Without such reconfiguration or a proper prefix withdrawal from the router, I don't think this particular scenario can reasonably be considered an operating system failure.

Hi, thank you for your tests.
That's another bug that I should address, I want this to be limited to PR298533.