Re: [RFC] ipv6: use a random ifid for headerless devices
From: Bjørn Mork <bjorn@mork.no>
Date: 2015-12-14 21:43:37
Hannes Frederic Sowa [off-list ref] 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 :)
quoted
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.
quoted
quoted
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.quoted
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