* Fwd: [Babel-users] policy routing
[not found] ` <CAA93jw5cmTiPgCS3JOTmNUF9Ykx7MjryV3-hM1w_NX50w_z4nQ@mail.gmail.com>
@ 2012-02-05 3:25 ` Dave Taht
2012-02-05 4:27 ` Dave Taht
0 siblings, 1 reply; 2+ messages in thread
From: Dave Taht @ 2012-02-05 3:25 UTC (permalink / raw)
To: bloat-devel
[-- Attachment #1: Type: text/plain, Size: 5905 bytes --]
While this takes the form of a rant, I have been rather slowly building up
a set of ip6tables,
iptables, and ip rules that almost, sort of, kind of, handle the exterior
gateway and interior
gateway problems that ipv6 introduces, and it really isn't
My open questions are:
Is there a routing protocol that does source and dest based routing?
Has anyone built up a set of ipv6 filters/rules already that can handle at
least some of the cases listed below?
---------- Forwarded message ----------
From: Dave Taht <dave.taht@gmail.com>
Date: Sun, Feb 5, 2012 at 4:22 AM
Subject: Re: [Babel-users] policy routing
To: Juliusz Chroboczek <jch@pps.jussieu.fr>
Cc: babel-users@lists.alioth.debian.org
On Sun, Feb 5, 2012 at 1:55 AM, Juliusz Chroboczek <jch@pps.jussieu.fr>wrote:
> >> However the problem of dealing with ipv6's various forms of addressing
> has
> >> O(n) complexity, it seems, so multiples of tables seem needed.
>
> Dave, you're confused, as usual.
I enjoy being loudly confused, and roundly, and even sometimes loudly,
enlightened.
And I note this discussion is forking off my original question, which was
basically
involving sane ways to come up with means of correctly routing or not
routing various forms of non-single provider ipv6 connectivity.
> There's no "problem" with the multiple
> forms of addressing in IPv6.
>
let's see:
ULA - this is the rough equivalent of rfc1918 address space in the ipv4
world. It's also the only ipv6 address space you can sanely use if you open
the box on a new router, and want to run ipv6 on it and your network rather
than or in addition to ipv4, and haven't plugged into a provider yet. It's
also a useful address space for private mesh networks as well... but it's
not routable to the internet...
ULA /48 addresses are randomly generated, which introduces a level 3 dns
problem, unless there is some magical way for an address like
fd03:024d:32ac::/48 to make it from being internally generated to the
users' eyeballs, perhaps via baudot code from the blinkenlights on the
front...
Native, static: Hoo-ray! this is what we thought the world would get! One
static ip address range for all eternity. Until we realized that people
move, that offices have multiple locations, and that providers go under,
and that BGP route tables got kind of big and can be easily fat fingered...
Native, PD. PD appears to be the way the world is going at the moment,
meaning that people will continue to 'rent' their addresses, and they may
go away or change at any time. Worse, at least in the initial roll-outs I'm
aware of, the address space may be as small as a single /64, and rarely as
large as a /56...
Native, PI - Let me know when I can get me some of those, and from whom.
6to4, 6RD, 6in4 - despite multiple attempts to deprecate these, they are
the only ways to get /48 connectivity and also where they work, are
actually deployed, and work fairly well....
6to4 and 6RD have the same dynamic assignment and removal problems that PD
does, and 6in4 requires tunnels often to far-off-lands...
Teredo - on by default on windows...
Multicast... wouldn't it be great if multicast worked? Wouldn't it be great
if we knew how to make it just work? Wouldn't it be great if world peace
was also achieved?
NAT. Yes, there are patches going around for ipv6. It seems inevitable...
VPNs. I'd like to connect 3 offices together, and have their separate
routing tables do the right thing...
Mobile IPv6... let's not talk about that...
HIP. Have I added enough complexity yet?
So what aspect of the 'ipv6 has no addressing problems' question did I not
express properly?
The specific case I was merely trying to cope with was in refusing to route
default routes
from the wrong place(s) and also try to ensure that that information got
pushed closer to
each interior gateway.
> The problem is with the ingress filtering policies of your upstream
> ISPs.
*A* problem
> The clean solution is to use a single upstream ISP
So you are suggesting that everyone you might want to mesh with to use a
monopoly ISP?
>, or to use PI
space and make sure your upstreams accept packets sourced with your
address.
So you want to convince multiple providers to allow multihoming?
> If you cannot do that, put a full mesh of GRE tunnels between your
> Internet gateways
Losing useful metrics and introducing n complexity, as well as tunneling
overhead.
> , and put a bunch of source policy rules to make sure
> each packet gets routed through the right gateway for its source
> address. Assuming the case of n upstreams, that's n gateways, and n-1
> tunnels originating on each gateway. Since there's no reason to have
> more than two upstreams (the cheap one and the reliable one), that's
> very reasonable.
>
Consider an apartment building. You play games regularly with your
downstairs neighbor,
he exchanges files with the gal across the hall, she has a wireless link
beaming down
to her favorite coffee shop, the coffee shop has links to the vpn back to
costa rica,
the costa-rican office has ties to several dozen more coffee shops, the
government,
and the local military...
and each gets their service from a different ISP...
> > I was trying to come up with a sane set of filters using the filter
> > rules, and failed.
>
> Please try again.
>
I am learning more about the ip rule database system, and babel's filters,
and missing functionality in ipv6tables than I ever wanted to know.
than I ever wanted to know...
> -- Juliusz
>
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
[-- Attachment #2: Type: text/html, Size: 8326 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread