netdev - Re: [PATCH v3 net-next 1/1] Allow user to set metric on default route learned via Router Advertisement.

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-next>] [day] [month] [year] [list]

Message-ID: <bc855311-f348-430b-0d3c-9103d4fdbbb6@gmail.com>
Date:   Fri, 22 Jan 2021 22:16:41 -0700
From:   David Ahern <dsahern@...il.com>
To:     Maciej Żenczykowski <zenczykowski@...il.com>
Cc:     Praveen Chaudhary <praveen5582@...il.com>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, corbet@....net,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki Yoshifuji <yoshfuji@...ux-ipv6.org>,
        Linux NetDev <netdev@...r.kernel.org>,
        linux-doc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Zhenggen Xu <zxu@...kedin.com>
Subject: Re: [PATCH v3 net-next 1/1] Allow user to set metric on default route
 learned via Router Advertisement.

On 1/22/21 9:02 PM, Maciej Żenczykowski wrote:
> Why can't we get rid of the special case for 0 and simply make 1024 the
> default value?

That would work too.

> 
> As for making it an RA option: it's not clear how that would work, the
> use case I see for this is for example two connections to the internet,
> of which one is clearly better (higher throughput, lower latency, lower
> packet loss, etc) then the other.
> 
> The upstream routers would have to somehow coordinate with each other
> the metric values... that seems impossible to achieve in practice -
> unless they do something like report expected down/up
> bandwidth, latency, etc...  While some sort of policy on the machine
> itself seems much more feasible (for example wired interface > wireless
> interface > cell interface or something like that)

I was thinking the admin of the network controls the RAs and knows which
paths are preferred over the admin of the node receiving the RA (not
practical for a mobile setup with cell vs wifi, but is for a DC which is
the driving use case).

But it takes an extension to IPv6/ndisc to add metric as an RA option,
so not realistic in a reasonable time frame.