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]
Date:	Mon, 15 Apr 2013 09:58:48 +0200
From:	Wilco Baan Hofman <wilco@...nhofman.nl>
To:	netdev@...r.kernel.org
Subject: ECMP ipv6 vs ipv4

Hi,

I'm working on a patch to implement 'nexthop weight' for multipath ipv6.
However, the ECMPv6 implementation has a few flaws that are quite
annoying.

One of the flaws is that the netlink nexthop API is asymmetrical, you
can add nexthops through the netlink API, but when the result is
requested it is completely different, resulting in bird6 removing the
route as it does not match the initial route set.

Another one of the flaws is that if I add nexthop weight or algorithm
(weighted hash or weighted random) I need to add this to the main rt
node, this seems like an inefficient memory structure, as this needs to
be added to all the siblings as well.

I propose that we have a nexthop structure to an exclusive route,
similar what we have for IPv4, where we store the gateway, device and
weight for all nexthops and the algorithm in the route. This would make
the netlink API symmetrical again and fixes the n*n inefficiencies when
adding routes (all siblings need to know about all siblings).

What are your thoughts on this?

Regards,

Wilco Baan Hofman

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ