nd6: Fix regeneration of temp addresses in detached state

[pouria]

Summary

When an on-link prefix becomes detached, the kernel keeps
generating new RFC 8981 temporary addresses for that prefix.
Fix it by ignoring the detached addresses in regen_tmpaddr().
While here, change its return type to bool.

PR: 298533
MFC after: 3 days

Test Plan

To test it faster, decrease net.inet6.ip6.temppltime value to 490, and then remove the address configuration on rtadvd.
See PR298533 for steps to reproduce.

[pouria]

Tested and ready

[markj]

sys/netinet6/nd6.c

979

You might change this variable to be a bool as well.

1123

Where exactly does the RFC prescribe this behaviour? I can't immediately see.

1139

[pouria]

Address @markj comments.

sys/netinet6/nd6.c

1123

That section starts by referencing RFC4862 and continues with "This document extends [RFC4862]".
Since it was the first commend of that function, I thought it might be a good idea to referencing its RFC there.
But you're right, it might be confusing.

[zarychtam_plan-b.pwste.edu.pl]

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.

[zarychtam_plan-b.pwste.edu.pl]

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.

[pouria]

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.