netdev - Re: [PATCH net-next] net: ipv6: put autoconf routes into per-interface tables

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]

Message-Id: <20170111.091139.1754139535517451753.davem@davemloft.net>
Date:   Wed, 11 Jan 2017 09:11:39 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     lorenzo@...gle.com
Cc:     temnota.am@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: ipv6: put autoconf routes into
 per-interface tables

From: Lorenzo Colitti <lorenzo@...gle.com>
Date: Wed, 11 Jan 2017 02:47:55 +0900

> On Tue, Jan 10, 2017 at 10:21 PM, Andrey Jr. Melnikov
> <temnota.am@...il.com> wrote:
>>
>> > >>> I have no firsthand experience of this myself, but if the problems
>> > >>> that Andrey reports above in this thread are real, then those would
>> > >>> indicate that the code is not well-supported. Being unable to accept
>> > >>> DAD is a pretty serious issue. Andrey, what version of the kernel did
>> > >>> you see this on?
>>
>> Good catch. I'm running 4.8 without this patch. Current 4.10-rc works. Sorry
>> for noise.
> 
> Ack. As I said before, I haven't seen this myself. Shouldn't have made
> assertions without firsthand evidence.
> 
> That said, I think this patch is useful even though autoconf on VRFs
> works the same way. One reason is the example I provided above: it
> works even for interfaces that don't exist yet, whereas a VRF has to
> be created ahead of time, which means that the interface cannot
> immediately come up and receive an RA or its configuration will be
> incorrect.
> 
> I also think that from a configuration perspective it's not
> necessarily useful to have one VRF for every interface, but that sort
> of depends on your point of view. Perhaps it's fine on a client system
> to have both vrf-wlan0 and wlan0, and vrf-eth0 and eth0. That might be
> confusing to users but maybe users don't really care?
> 
> More in general I think that using a VRFs is buying into a bigger set
> of assumptions/restrictions than this patch does. For example, if I'm
> reading ipv6_dev_get_saddr correctly, once you put an interface in a
> VRF you can't really use the weak host model any more, because the
> stack won't pick a source address from outside the VRF if the route
> lookup returned a route in the VRF. Turning on the functionality in
> patch is a more minimal change that only affects autoconf.

I understand what you're saying, but if you look at how apps can be
put into hierarchical control groups, and automatically bind to VRF's
based upon where they are in that cgroup hierarchy, it matches your
use case precisely.

Maybe the setup is not ideal, but architectually it does everything
you want.  And we strongly try to avoid adding multiple ways to do the
same thing.