From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: netdev@vger.kernel.org, 吉藤英明 <hideaki.yoshifuji@miraclelinux.com>
Subject: Re: [RFC] ipv6: use a random ifid for headerless devices
Date: Tue, 8 Dec 2015 14:44:13 +0100 [thread overview]
Message-ID: <5666DEAD.6010202@stressinduktion.org> (raw)
In-Reply-To: <87d1ukk9ce.fsf@nemi.mork.no>
On 05.12.2015 20:02, Bjørn Mork wrote:
> Hannes Frederic Sowa <hannes@stressinduktion.org> writes:
>> On Thu, Dec 3, 2015, at 20:29, Bjørn Mork wrote:
>>
>>> After looking more at addrconf, I started wondering if we couldn't abuse
>>> ipv6_generate_stable_address() for this purpose? We could add a new
>>> addr_gen_mode which would trigger automatic generation of a secret if
>>> stable_secret is uninitialized. This would be good enough to ensure
>>> stability until the interface is destroyed. And it would still allow
>>> the adminstrator to select IN6_ADDR_GEN_MODE_STABLE_PRIVACY by entering
>>> a new secret.
>>
>> I am fine with your proposal but I would really like to see it only
>> happen on the per-interface stable_secret instance.
>
> Do you think something like the patch below will be OK?
I wouldn't call it IN6_ADDR_GEN_MODE_AUTO, this doesn't say anything.
But the idea is already good.
> Or would it be better to drop the additional mode and just generate a
> random secret if the mode is IN6_ADDR_GEN_MODE_STABLE_PRIVACY and the
> secrets are missing? Or would that be changing the userspace ABI? This
> is not clear to me...
I would not like to do that somehow. The problem is that the stable
secrets get written by user space probably during boot-up, but we don't
know when. That's why I would also not set the ->initialized flag, so
user can overwrite it to the final secret later on. We block it otherwise.
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.
What do you think?
Bye,
Hannes
next prev parent reply other threads:[~2015-12-08 13:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-30 11:55 [RFC] ipv6: use a random ifid for headerless devices Bjørn Mork
2015-11-30 12:01 ` 吉藤英明
2015-11-30 13:55 ` Bjørn Mork
2015-12-01 7:39 ` YOSHIFUJI Hideaki
2015-12-01 11:22 ` Hannes Frederic Sowa
2015-12-03 19:29 ` Bjørn Mork
2015-12-04 10:41 ` Hannes Frederic Sowa
2015-12-05 19:02 ` Bjørn Mork
2015-12-08 13:44 ` Hannes Frederic Sowa [this message]
2015-12-08 18:57 ` Bjørn Mork
2015-12-14 21:30 ` Hannes Frederic Sowa
2015-12-14 21:43 ` Bjørn Mork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5666DEAD.6010202@stressinduktion.org \
--to=hannes@stressinduktion.org \
--cc=bjorn@mork.no \
--cc=hideaki.yoshifuji@miraclelinux.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).