From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C1E6121F1A6 for ; Wed, 8 May 2013 15:47:01 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/38117) with ESMTP id r48MkheG028532; Thu, 9 May 2013 00:46:43 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 457274C692; Thu, 9 May 2013 00:46:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ohxCRESFecb; Thu, 9 May 2013 00:46:42 +0200 (CEST) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 017754C680; Thu, 9 May 2013 00:46:41 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UaD8J-000520-NG; Thu, 09 May 2013 00:46:47 +0200 Date: Thu, 09 May 2013 00:46:47 +0200 Message-ID: <8738txgkdk.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Dave Taht Subject: Re: [homenet] Source-specific routes in Linux [was: atomic updates...] In-Reply-To: References: <87vc6vgghx.wl%jch@pps.univ-paris-diderot.fr> <8F7177E4-6212-4A74-8A7C-A2D1703A59BF@iki.fi> <87sj1zgfot.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 09 May 2013 00:46:44 +0200 (CEST) X-Mailman-Approved-At: Thu, 09 May 2013 02:16:43 -0700 Cc: homenet@ietf.org, Markus Stenberg , bloat-devel , boutier@pps.univ-paris-diderot.fr X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 22:47:02 -0000 >   http://www.spinics.net/lists/netdev/msg235316.html >   http://www.spinics.net/lists/netdev/msg235346.html > One thing that bugs me about hacks and workarounds like this is that Linux (as > well as openwrt) are intensely mutable systems, and it's totally possible to > improve linux rather than limp around in userspace. I can only agree with you. Now, as mentioned in my second message linked above, source-specific routing for IPv6 in a single table appears to be supposed to work with CONFIG_IPV6_SUBTREES. My tests indicate it doesn't, at least in recent kernels. I've tried to look at the relevant code (in ipv6/ipv6_fib.c and ipv6/route.c), and this code is way beyond my grokking abilities. Should a friendly kernel hacker choose to fix this, we can switch our implementation to using that simpler API with little effort. (Acutally deleting a bunch of code -- Matthieu is going to hate me.) > I have long disliked the ip rule system in its primary use prior to now > (vpns), as buggy, arbitrary, and subject to race conditions, so if a better > api and methods for injecting/managing source address dependent routing My preference goes towards dumping all routes into a single routing table. This applies both to source-specific routes, to input-interface specific routes (which is what Steven Barth was referring to), as well as to any future extensions to the model (TOS-specific routes, flow-id-specific routes, evil-bit-specific routes, etc.) The semantics of such an API is ambiguous, but userspace can work around that by injecting extra routes into the FIB. The number of such routes is at worst proportional to r^s, where r is the number of "real" routes and s is the number of selection mechanisms, but (1) this worst case is unlikely to happen in practice, and (2) this number can be greatly reduced by having reasonable default disambiguation rules in the kernel (use the destination as the primary key, the source as the secondary key, and any other selectors as the tertiary key). -- Juliusz