Fwd: [Babel-users] policy routing

Fwd: [Babel-users] policy routing

[Dave Taht]

[-- 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 --]

Re: [Babel-users] policy routing

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 3110 bytes --]

On Sun, Feb 5, 2012 at 3:25 AM, Dave Taht <dave.taht@gmail.com> wrote:

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

^^^fun.

To add to the fun, let me talk to the ipv6 naming problem... I realize that
ipv6 is not 'bloat', however:

A) we are attempting to treat ipv6 as a first class protocol throughout, in
testing, and building AQMs. No shaper that I know of is doing entirely the
right thing in the presence of ipv6, I'd like to correct that. Take for
example, multicast... please.

Absolutely everything in the bloatlab, and in cerowrt, are ipv6 enabled....

B) tunneling of various sorts introduces interesting problems for shapers...

C) Certain things we think are worthwhile to do (such as ECN) may only be
possible to roll out on ipv6...

D) Fixing bloat, home cpe, and ipv6 all at the same time saves on two
truckrolls.

So, I digress into my own problem in trying to create usable ipv6 testbeds,
which is how this thread sort of started.

While I'm going to pick on bind9 here, it also applies to many other
applications.

1) bind9 attempts to bind to all interfaces individually. This includes
internal interfaces such as 'ifbX', which are not really interfaces at all.
Similar issues with various tunneled interfaces. You can of course, use
acls, but those are static, and there is no way to use a pattern that would
be - don't bother with this interface (I think)

2) Or, you could maybe just bind to *, but then you'd have to use some sort
of pattern on the acls so that your *:*:*:00FF::/56 was your internal
network... or maybe try to use anycast, if anyone can explain how to use
anycast without BGP....

2) Interfaces are dynamic. Wireless ones in particular. So bind polls for
new interfaces on a configurable basis. Assuming you are actually routing
stuff well, it pays to merely make bind available on two ipv6 addresses,
one internal, one external, so you can implement views.

3) But IPv6 addresses change. The one you want might not be available on
boot...
There seems to be no means to be alerted of an address change on an
interface in Linux. Lacking such a message (does one exist?), it polls for
that too...

 Then we get to the naming problem. I'd like to think we have that one
licked (back in june of last year, leveraging dhcp information to inform
the dns server of ipv6 autoconfig info), except that coping when ipv6
addresses change for whatever reason (power failures, being withdrawn by
the isp, a physical move, you have a 2^64 name space to cleanup or rename,
somehow.... or when one gets added to an existing device, or when there are
private and public ips in play.... or when you are using stateful
configuration in an environment that may not have that working entirely...


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net

[-- Attachment #2: Type: text/html, Size: 3513 bytes --]