IPv6: rc boot time improvements

[bz]

Summary

This is a first cut to improve boot time for IPv6.
Hisotrically we did sleep quite a lot more than we needed.

If IPv6 is enabled we call rtsol on that interface so waiting in
rtsold is counterproductive; if one was to just use rtsold -F then
they are on their own for having the addresses usable during the
remaining startup time.

Rather than sleeping dad_count + 1 seconds we are now checking for
any tentative addresses on the interface and only then slee
dad_count up-to 2 times. This should not save us anything with the
defaults but there are too many assumptions invovled anyway
(RETRANS_TIMER in the kernel being 1000ms being one).
The reason why we need to sleep more than dad_count (1s default)
seems to be that first DAD for the link-local address clears and
only then solicited (or other global) addresses are handled.

[bz]

Just a first cut for your testing to see what difference it makes?
I would assume you'd sleep 2 rather than 4 seconds.

I'll add reviewers once we have initial results.

libexec/rc/network.subr

51

This is unrelated for this and should be a follow-up to an old commit I once did ... (lookup hash and factor out here). Should not matter anyway.

1749

This should be done separately as well; we are only interested in inet6 addresses so avoid printing a load of other stuff.

[bz]

More unrelated noise in the change.

libexec/rc/rc.d/netif

228

Also unrelated: moving the interfaces between vnets does not need DAD as we should never move addresses (link-local maybe on the vnetdown case) but really interface address configuration in that case is what matters and not the interface appearing.

[cperciva]

On the IPv4 side, when /etc/rc.d/dhclient runs, it gets an IPv4 address before the dhclient process is backgrounded and the boot process continues; so anything which comes later in the boot process is guaranteed to see the necessary addresses.

On the IPv6 side, I don't think we have any sort of deliberate wait-for-addresses-to-arrive... except that we might be getting that accidentally thanks to the extra sleeping here?

[bz]

This has been lingering here for half a decade it seems. Anyone interested in looking into this / if it makes sense (take over the review)? Otherwise I'll abandon it in a few days.

[bms]

Misread as "full decade", and, given DAD is the first boot time excursion into MLD... have at it. +1.

[pouria]

I will take a look

[pouria]

This looks good to me. Definitely better than blindly sleeping on dad_count.
But I'm not an expert in shell scripting.
Let me ask and I'll add more reviewers for scripting part.

[dteske]

libexec/rc/network.subr

1749

When done separately, consider copying your here-doc style implementation for getting tentative to avoid the obvious fork that a pipe induces. It did not go unnoticed that you took the care to avoid using pipe in network6_gettentative() and the change here to do the same would be simple, move the ${IFCONFIG_CMD} $_if inet6 2>/dev/null inside a heredoc that is bolted onto the done

1804

If this line uses test instead of [ then it will be the only if/while line that does-so which would in-turn mean 97.8% of the file uses [ (100% of 46 already-present lines uses [ instead of test). Meanwhile, if you switch this line to using [ then the file can remain 100% using [ for all if/while statements

Also, consider using && instead of -a if you'd like to adhere to the POSIX "rule of 4" which claims that test (aka [) only guarantees functionality of up to 4 positional arguments (read: they don't regression test ad-infinitum)

libexec/rc/rc.d/netif

219

&& (like || and |) are "r-value seeking operands" meaning you do not need the line-continuation here, && will seek past the newline to get its r-value.

ASIDE: r-value here means "right-half of the binary operand" (i.e., l-value && r-value)