On Tue, Jan 10, 2017 at 10:21 PM, Andrey Jr. Melnikov <temnota...@gmail.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.
