Re: [RFC] ipv6: use a random ifid for headerless devices

["Bjørn Mork" <bjorn@mork.no>]

Hannes Frederic Sowa <hannes@stressinduktion.org> writes:

> Sorry for answering so late...

No problem.  There is no rush here AFAICS.  Thanks for taking the time
to look at this.

> What do you think about simply using IN6_ADDR_GEN_MODE_RANDOM?

Yes, that's fine with me (actually what I first used :)

>> I guess we should check &net->ipv6.devconf_dflt->stable_secret too
>> before choosing the default mode.  IN6_ADDR_GEN_MODE_STABLE_PRIVACY is a
>> more approproate default if a default secret is set.  IMHO, this should
>> really be the case without the proposed change too, but it isn't. The
>> current behaviour confuses me: Setting 'default' changes all existing
>> interfaces, but does not change the default for new interfaces. Is that
>> right?
>
> Nope, that is a good point. I think we should do that unconditionally.
> If we have a stable secret set, which we can use, we always should use
> this address generation mode. Can you send the addition of this as a
> separate patch so we can propose it for stable? Otherwise I can do that,
> too.

I can do that if it can wait for whenever I get around to actually
submit this.  No guarantee that will be in time for v4.5.


>>> My proposal would be to use the stable privacy generator in case the
>>> device does not have a device address for EUI-48 generation with a
>>> secret which we simply generate on the stack. Let's factor out the part
>>> of the generator which depends on the inet6_dev and cnf bits for that.
>> 
>> Not sure I get this part either.  The point was to have stable addresses
>> for the lifetime of the netdev.  We can generate the secret on the
>> stack, but we will still need to stash it somewhere.  That could of
>> course be to a new field.  But I don't see the point since there is no
>> way you can combine this mode with IN6_ADDR_GEN_MODE_STABLE_PRIVACY.
>> Only one mode can be active at, and that mode can then own the secret.
>
> Ok, your argument makes sense.
>
>> As long as we can manage to introduce this without changing any existing
>> behaviour, of course.
>
> Besides the naming I think your patch looks fine.

Thanks!  Will fixup that and formally submit when I find some time.


Bjørn