rtsold: handle media LINK_UP to accelerate RS/RA

[bz]

Summary

If a link is not UP at boot time, e.g., a cable gets plugged in later,
rtsold will not send out an RS and we have to wait for the next
unsolicitated RA to get a default router, prefix information, etc.

Hook into rtsolds routing message callback handler and rather than
complicating logic, simply re-set the internal timer if we find a link
UP and RUNNING (based on the rtmsg), and let the rtsold state machine
do the work.

---

I wrote this in response to D56927 but never tested it.
I would appreciate if someone could test/review.

XXX-BZ also, is there a reference in an RFC related to this which we can/should
mention about this case?

[pouria]

It helps, but not much. it might increase ifi->timer.tv_sec to PROBE_INTERVAL which is 60s.

usr.sbin/rtsold/rtsock.c

183

191

Why do we need IFF_RUNNING here?

194

After some debugging, I found out rtm_index is not same as ifm_index.

[bz]

In D58211#1335366, @pouria wrote:

It helps, but not much. it might increase ifi->timer.tv_sec to PROBE_INTERVAL which is 60s.

So just doing the timer update is not enough? I wonder how we get it into a "reset" state to start running like on startup then without massive fiddling?

usr.sbin/rtsold/rtsock.c

191

Because if the interface is not UP and RUNNING you cannot transmit and so it would defeat the purpose.

194

That is a very good catch!

[zarychtam_plan-b.pwste.edu.pl]

The motivation for writing D56927 was to trigger a Router Solicitation immediately after the interface media becomes available, in order to achieve faster convergence by prompting the gateway to send a Router Advertisement. It works this way:

16:12:25.985907 IP6 fe80::1265:30ff:fe7a:9509 > ff02::2: ICMP6, router solicitation, length 16
16:12:25.989220 IP6 fe80::360a:98ff:fe1b:404e > ff02::1: ICMP6, router advertisement, length 104

A single ICMPv6 Router Solicitation message is sent on the interface, and the received Router Advertisement promptly helps configure the interface that has just been brought up.

Unfortunately, after testing this patch, I can only conclude that it needs further development before it can reliably work as intended.

[zarychtam_plan-b.pwste.edu.pl]

At the end of Section 3.6 of RFC 8981, we can read the following:
"Finally, when an interface connects to a new (different) link, existing temporary addresses for the corresponding interface MUST be removed, and new temporary addresses MUST be generated for use on the new link, using the algorithm in Section 3.4. If a device moves from one link to another, generating new temporary addresses ensures that the device uses different randomized IIDs for the temporary addresses associated with the two links, making it more difficult to correlate addresses from the two different links as being from the same host. The host MAY follow any process available to it to determine that the link change has occurred. One such process is described by "Simple DNA" [RFC6059]. Detecting link changes would prevent link down/up events from causing temporary addresses to be (unnecessarily) regenerated."

This means that, sooner or later, rtsold(8) on FreeBSD should be redesigned to properly handle interface up/down events. In particular, the daemon would need to monitor the state of each interface and distinguish between a simple interface state change and a transition to a different link.