Date:	Tue, 29 Oct 2013 15:38:47 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Dan Williams <dcbw@...hat.com>
Cc:	David Miller <davem@...emloft.net>, jiri@...nulli.us,
	vyasevich@...il.com, netdev@...r.kernel.org, kuznet@....inr.ac.ru,
	jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net,
	thaller@...hat.com, stephen@...workplumber.org
Subject: Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag

Hi!

On Tue, Oct 29, 2013 at 09:31:18AM -0500, Dan Williams wrote:
> On Tue, 2013-10-29 at 00:48 +0100, Hannes Frederic Sowa wrote:
> > On Mon, Oct 28, 2013 at 06:16:19PM -0500, Dan Williams wrote:
> > > On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> > > > From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> > > > Date: Sun, 27 Oct 2013 17:48:35 +0100
> > > > 
> > > > > A temporary address is also bound to a non-privacy public address so
> > > > > it's lifetime is determined by its lifetime (e.g. if you switch the
> > > > > network and don't receive on-link information for that prefix any
> > > > > more). NetworkManager would have to take care about that, too. It is
> > > > > just a question of what NetworkManager wants to handle itself or lets
> > > > > the kernel handle for it.
> > > > 
> > > > How much really needs to be in userspace to implement RFC4941?
> > > > 
> > > > I don't like the idea that even for a fully up and properly
> > > > functioning link, if NetworkManager wedges then critical things like
> > > > temporary address (re-)generation, will cease.
> > > 
> > > Honestly, I'd be completely happy to leave temporary address handling up
> > > to the kernel and *not* do it in userspace; the kernel already has all
> > > the code.  There are two problems with that though, (a) it's tied to
> > > in-kernel RA handling, and (b) it's controlled by a CONFIG option.  Both
> > > these are solvable.
> > 
> > Ah, (a) does complicate things, I agree. But the tieing is essential
> > currently. So it seems a netlink interface would be needed to tie a new
> > address to an already installed one, if the kernel should still deal
> > with the regeneration?
> 
> I think it's simpler than that.  New flag set when adding the
> non-private address that says "create and manage privacy addresses for
> this non-private address".  The kernel then adds the privacy addresses
> generated off the non-private address/prefixlen, and ties their lifetime
> to the non-private address.  If the non-private address is removed, the
> privacy addresses could get removed too.
> 
> I don't think we need API to tie addresses to already installed ones,
> because the kernel already has the privacy address generation code, so
> why should userspace generate the privacy address at all?  Just leave
> that to the kernel.

Ok.

> > > First off, what's the reasoning behind having IPv6 privacy as a config
> > > option?  It's off-by-default and must be explicitly turned on, so is
> > > there any harm in removing the config?  Or is it just for
> > > smallest-kernel-ever folks?
> > 
> > I don't know about the policy. Does it really matter as distributions
> > normally switch it on? But I would not like to see the option removed
> > entirly, maybe the default could be changed.
> > 
> > > Would a new IFA_F_MANAGE_TEMP (or better name) work here, indicating
> > > that for some new static address, that the kernel should create and
> > > manage the temporary privacy addresses associated with its prefix?
> > 
> > But this would only be needed if they were managed in user-space, no?
> 
> "if they" == what?  privacy address or static address?  What

With "they" I meant privacy addresses.

> NetworkManager is trying to do is handle RAs in userspace with libndp
> for various flexibility and behavioral reasons, but we'd really like to
> leave all the temporary address stuff up to the kernel.

Can you provide me with details why the Kernel RA implementation is not good
enough? I tried to find some bugs, I found some but they were missing details
or were not even correct or outdated.

> So NM would handle RA/RS and when it gets a prefix, it would create the
> IPv6 non-private address and add it to the interface.  When adding, it
> would also set the "IFA_F_MANAGE_TEMP" flag (or whatever) and the kernel
> would then handle all the privacy address generation, lifetimes, and
> timers.  Basically, break some of the privacy code away from the
> in-kernel RA handling so that privacy addresses could be triggered from
> userland too.
> 
> Would that be workable?

That sounds like a solid plan for me. I would actually liked to see that NM
would use the kernel implementation but I guess there is no way back any more.
:(

Greetings,

  Hannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists