lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 6 Jan 2014 17:01:39 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Thomas Haller <thaller@...hat.com>
Cc:	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
	stephen@...workplumber.org, dcbw@...hat.com
Subject: Re: [patch iproute2 v2 0/2] add support for IFA_F_MANAGETEMPADDR

On Mon, Jan 06, 2014 at 04:41:49PM +0100, Thomas Haller wrote:
> On Sat, 2014-01-04 at 12:35 +0100, Hannes Frederic Sowa wrote:
> > On Sat, Jan 04, 2014 at 12:21:51PM +0100, Thomas Haller wrote:
> > > > > >Also, I saw that NetworkManager switched to install autoconf addresses
> > > > > >as /128, doesn't this break with IFA_F_MANAGETEMPADDR, as you expect a /64
> > > > > >prefixlen?
> > > > > 
> > > > > /64 is required
> > > > 
> > > > Ok, currently NM seems to "violate" that as it installs autoconf addresses
> > > > with 128 prefixlen, so IFA_F_MANAGETEMPADDR should not work on them.
> > > > (currently observed on Fedora 20).
> > > 
> > > True, I noticed that too. I think that is a bug in NM to add the
> > > addresses as /128. Probably, we will fix that soon.
> > 
> > The change could be valid. Otherwise currently NM could not correctly handle
> > prefix information in RAs in some cases:
> > 
> > It is possible to let the client generate an autonomously address in a
> > prefix which is actually not on-link (L=0). Kernel would automatically
> > create prefix route by mistake, if NM tries to install such an address
> > with /64 prefix. This does not happen if the prefix address uses 128
> > prefixlen.
> > 
> > Would be great to have feedback on this, as this could be easily solved by an
> > additional ifa_flag.
> > 
> > Greetings,
> > 
> >   Hannes
> > 
> 
> 
> Hi Hannes,
> 
> 
> good point. I think, the user-space application (NetworkManager) should
> add the autoconf addresses as /64. But the kernel should not generate
> any routes in that case. It's up to the application to add them
> (depending on the on-link flag).
> 
> 
> What do you think about something like:

I would introduce a new flag for that and also make it accessible via
iproute, maybe later. Otherwise IFA_F_MANAGETEMPADDR is overloaded and
doesn't do justice to its name. And since Jiri made new room in ifa_flags,
it shoud be no problem. ;)

Btw. while just reviewing anycast changes, I noticed a funny thing:
Kernel does allocate an anycast address which is the same as the autoconf
address, if NM installs /128 address and you have ipv6 forwarding enabled
(fedora 20 install + ipv6 forwarding because of libvirt). You can see the
addresses pop up in /proc/net/anycast6. I currenlty don't know if that
is problematic.  Everything seems to work here for me. ;)

In the end, I don't think we should install anycast for /128, but I am not
sure, yet.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ