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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKD1Yr2U2Oh5yvHE7Znfc9mHzM4K6B_kU82Qctpcsmnt3y5GdQ@mail.gmail.com>
Date:   Tue, 10 Jan 2017 11:01:44 +0900
From:   Lorenzo Colitti <lorenzo@...gle.com>
To:     David Ahern <dsa@...ulusnetworks.com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Maciej Żenczykowski <zenczykowski@...il.com>,
        Hannes Frederic Sowa <hannes@...essinduktion.org>,
        Erik Kline <ek@...gle.com>,
        YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>,
        David Miller <davem@...emloft.net>,
        Daniel Rosenberg <drosen@...gle.com>
Subject: Re: [PATCH net-next] net: ipv6: put autoconf routes into
 per-interface tables

On Sun, Jan 8, 2017 at 1:24 PM, David Ahern <dsa@...ulusnetworks.com> wrote:
> Why not use the VRF capability then? create a VRF and assign the interface to it. End result is the same -- separate tables and the need to use a bind-to-device API to hit those routes.

Requiring that VRFs for this creates additional complexity, because
each network now requires its own VRF. That means that the connection
manager must create the VRF before the interface comes up and receives
the RA.

In some cases this might not be possible. For example, consider a tun
interface that's created by a different process such as a VPN client.
In this case the connection manager doesn't know the interface name,
and the VPN client doesn't know to create the VRF, so if the tun
interface gets an RA after the tun is created but

As others have mentioned, IPv6 on VRFs in client mode is also not
necessarily well-supported at the moment, and I don't know how long it
would take for it to be (assuming it can be made to work properly in
client mode without breaking the primary use cases for VRFs).