Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: Ole Troan <otroan@employees.org>
To: Steven Barth <cyrus@openwrt.org>
Cc: bloat-devel <bloat-devel@lists.bufferbloat.net>,
	Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>,
	Markus Stenberg <markus.stenberg@iki.fi>,
	Ole Troan <otroan@employees.org>,
	boutier@pps.univ-paris-diderot.fr, homenet@ietf.org
Subject: Re: [homenet] Source-specific routes in Linux [was: atomic	updates...]
Date: Wed, 8 May 2013 12:58:52 +0200	[thread overview]
Message-ID: <4731AFEA-6D92-4201-BEA5-46B535C84657@employees.org> (raw)
In-Reply-To: <3c2ea3e2-a587-4cf6-820b-929e6d75a9ad@email.android.com>

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.
>> 
>> 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.
>> 
> 
> 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. 

cheers,
Ole

  reply	other threads:[~2013-05-08 10:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-05 21:38 Dave Taht
2013-05-05 22:23 ` Dave Taht
     [not found]   ` <loom.20130507T130051-512@post.gmane.org>
     [not found]     ` <87vc6vgghx.wl%jch@pps.univ-paris-diderot.fr>
     [not found]       ` <8F7177E4-6212-4A74-8A7C-A2D1703A59BF@iki.fi>
     [not found]         ` <87sj1zgfot.wl%jch@pps.univ-paris-diderot.fr>
2013-05-08  8:51           ` [homenet] " Dave Taht
2013-05-08  9:48             ` Steven Barth
2013-05-08 10:28               ` Ole Troan
2013-05-08 10:51                 ` Steven Barth
2013-05-08 10:58                   ` Ole Troan [this message]
2013-05-08 12:54                     ` Steven Barth
2013-05-08 11:06                   ` Lorenzo Colitti
2013-05-08 22:46             ` Juliusz Chroboczek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4731AFEA-6D92-4201-BEA5-46B535C84657@employees.org \
    --to=otroan@employees.org \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=boutier@pps.univ-paris-diderot.fr \
    --cc=cyrus@openwrt.org \
    --cc=homenet@ietf.org \
    --cc=jch@pps.univ-paris-diderot.fr \
    --cc=markus.stenberg@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox