On Sun, Jan 8, 2017 at 1:24 PM, David Ahern <d...@cumulusnetworks.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).
