[PATCH 3/3] babel: Add option to randomise router ID

[Ondrej Zajicek]

On Wed, May 09, 2018 at 04:29:54PM +0200, Toke Høiland-Jørgensen wrote:
> Ondrej Zajicek <santiago at crfreenet.org> writes:
> 
> > On Thu, May 03, 2018 at 03:14:58PM +0200, Toke Høiland-Jørgensen wrote:
> >> Ondrej Zajicek <santiago at crfreenet.org> writes:
> >> > Ignoring global setting is OK, i just wonder whether some global
> >> > EUI-64-based unique ID should not be provided directly by the nest
> >> 
> >> That might be convenient, yeah. There's the issue of picking the right
> >> interface, though; some kind of logic that says "first interface with a
> >> configured protocol"? Or should it be a per-protocol type thing?
> >
> > It would make sense to use an analogous mechanism to 32bit router id,
> > just use IPv6-LL address instead of IPv4 address. See 'router id' /
> > 'router id from' options and function if_choose_router_id().
> 
> Right, that makes sense. A 'v6-ll/64bit router id [from]' config option?

Something like that. I would prefer '64bit', but unfortunately keywords
in BIRD have to use {alpha}{alnum}* format.

It should also check if the address is really EUI-64 and skip configured
ones like fe80::1.

> The nest could provide proto_get_router_id64() which would return an
> LL-based ID if configured/available and the 32-bit version if it isn't?

Yes. Or just 64-bit ID could be set based on 32-bit value as a last resort.

> > One issue is that if BIRD is started during boot then IPv6-LL
> > addresses may not be available immediately after start due to waiting
> > for duplicate address detection.
> 
> Hmm, true. Should we deal with this (by deferring startup of protocols
> that need them, I guess?), or leave it up to administrators to fix their
> init scripts? With the fallback option mentioned above it would not be
> strictly necessary, we could just fall back to 32-bit... :)

Well, ignoring it is ugly and leads to nondeterministic behavior. Deferring
protocol startup could be hacked, but it is still problematic (e.g., you
have to rerun router id election when DUD finished for initial addresses).

Another option would be be to process even tentative addresses but mark
them in such way, so protocols could ignore them while router-id selection
could still use them.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."