Thread (12 messages) 12 messages, 3 authors, 2015-12-14

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help