From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.employees.org", Issuer "Equifax" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5292D21F1C5 for ; Wed, 8 May 2013 03:58:56 -0700 (PDT) Received: from dhcp-lys02-vla252-10-147-116-38.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 4BB275EB4; Wed, 8 May 2013 03:58:54 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [homenet] Source-specific routes in Linux [was: atomic updates...] From: Ole Troan In-Reply-To: <3c2ea3e2-a587-4cf6-820b-929e6d75a9ad@email.android.com> Date: Wed, 8 May 2013 12:58:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4731AFEA-6D92-4201-BEA5-46B535C84657@employees.org> References: <87vc6vgghx.wl%jch@pps.univ-paris-diderot.fr> <8F7177E4-6212-4A74-8A7C-A2D1703A59BF@iki.fi> <87sj1zgfot.wl%jch@pps.univ-paris-diderot.fr> <518A1F51.809@openwrt.org> <3c2ea3e2-a587-4cf6-820b-929e6d75a9ad@email.android.com> To: Steven Barth X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 09 May 2013 02:16:43 -0700 Cc: bloat-devel , Juliusz Chroboczek , Markus Stenberg , Ole Troan , boutier@pps.univ-paris-diderot.fr, homenet@ietf.org 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 10:58:56 -0000 Steven, >>> We have switched to RA-Handling in userspace for similar reasons >> already so I guess it's only the next logical step to create separate >> routing tables for each upstream interface to do source-based routing >> and filter out ULA-traffic on this layer instead of through iptables. >>=20 >> don't do it per upstream interface, that wouldn't work. per next-hop >> might. the draft suggests a single table with source constrained >> routers and backtracking. >>=20 >=20 > Ah yes thanks for the hint. Please correct me if I got this wrong: I = guess per interface would be problematic if there are multiple routers = on the upstream link offering different prefixes. However in case of = prefix delegation via DHCPV6-pd like on usual home ISP connections would = it not be problematic to attribute the prefix to any specific router? - = if there would be multiple routers which I guess is unlikely in that = situation. One could maybe attribute the prefix to the source address of = the DHCPv6 server but that sounds problematic to me aswell. Hmm did I = miss something or am I completely on the wrong track now? at least we're on the same track (and I think the correct one). ;-) on the border router this is quite simple. if a border router uses PD = and it discovers a default router on the same interface, that will result in a SADR route (S, D) -> interface, next-hop. where S = is PD prefix, D is ::/0, interface is the interface the PD was received on and next-hop is whatever router discovery came back with. the issue is with internal routers, where you may have an internal = router connected to two exits on the same link, or behind another IR that is connected to both..., i.e. arbitrary topology.=20 cheers, Ole=