Comment 4 for bug 107432

Hmm, I'm inclined to agree. Still, this draws my attention to the module loading behaviour of modprobe and its method of automatically loading modules as required:

alias net-pf-10 ipv6

... shouldn't this happen if/when the kernel attempts to register any address of this family, or route for that matter?

I don't use the aliases file much at all, I simply don't trust it, meaning I'm unfamiliar with how it works internally or how that would impact ifup/ifdown. Being old school, I hand-type the modules I use into /etc/modules, but even this would alleviate the problem.

In short, ===I don't see how module loading is any responsibility of ifup/ifdown to begin with===. Even PPP connections load the ppp module as required simply by executing pppd in any modern Linux environment.

That said, I don't particularly care which method is employed, as long as I can stop hand-patching each and every ifupdown installation on my network.

On the other hand, ===modprobe -Q should NEVER set a failure status=== as I understand it:

       -Q --silent
                 As -q with the addition that all warnings and errors are also
                 silenced.

This doesn't state that it must return a True value, but I think for the case of rapid or inconsequential execution, this fact seems implied to me. What we have here is two problems compounding to produce a strange (and inconvenient) result, but in my opinion they should both be fixed.

--

In respect to the default route designation, I don't see how this is required in a modern environment. Router advertisements should distribute next-hop routes automatically. In an environment where this isn't the case, either route designations should work with appropriate metrics.

The reason I changed the ::/0 to 2000::/3 in the patch was because ... well, metrics. fe80::/8 is within the realm of ::/0 if the route metric of ::/0 is set incorrectly. The route command doesn't provide any method of manually setting a metric, so we take its word for it that it is correct. Not ALL implementations do this properly, which results in broken anycast routing, hence breaking router adverts and so on.

I haven't seen this happen since one instance of Debian years ago, so ===it's probably a null issue at this point and that modification can be removed===. Still, I can't see any situation where it would break anything, except perhaps an otherwise operational (but broken by design) IPv6 network.