From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4D2BD200DE1 for ; Sat, 4 Feb 2012 19:25:33 -0800 (PST) Received: by werb14 with SMTP id b14so6320865wer.16 for ; Sat, 04 Feb 2012 19:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=GmwJGt6xb/VMv18LVB/6xp0bGehmi1PLctMGHBc9sE8=; b=HzpFJtG5ECu14X8VrTGC0rxKjLMq09ZvB4RhDyZUif/OlpOzjnrainx07Zexg8eW8C bhx1OCZW+7RHIbL85HTzEhf+8wan06QOp0P+u2qPpmb4OEsjI6Q7+KYELVzcxCWAhKV3 SfQySMUOre/YIrJkA8fhqLXDlPBlc5GaM5uMY= MIME-Version: 1.0 Received: by 10.216.139.165 with SMTP id c37mr27619wej.53.1328412331206; Sat, 04 Feb 2012 19:25:31 -0800 (PST) Received: by 10.223.119.212 with HTTP; Sat, 4 Feb 2012 19:25:31 -0800 (PST) In-Reply-To: References: <7ivcnmks6b.fsf@lanthane.pps.jussieu.fr> <7ifweq11td.fsf@lanthane.pps.jussieu.fr> Date: Sun, 5 Feb 2012 04:25:31 +0100 Message-ID: Subject: Fwd: [Babel-users] policy routing From: Dave Taht To: bloat-devel Content-Type: multipart/alternative; boundary=0016e6d976e31de7e304b82f1990 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: Sun, 05 Feb 2012 03:25:33 -0000 --0016e6d976e31de7e304b82f1990 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 Date: Sun, Feb 5, 2012 at 4:22 AM Subject: Re: [Babel-users] policy routing To: Juliusz Chroboczek Cc: babel-users@lists.alioth.debian.org On Sun, Feb 5, 2012 at 1:55 AM, Juliusz Chroboczek wrot= e: > >> 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 > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net --0016e6d976e31de7e304b82f1990 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While this takes the form=A0 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 sou= rce and dest based routing?

Has anyone built up a set of ipv6 filter= s/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 rout= ing
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> w= rote:
>> 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. =A0

I= enjoy being loudly confused, and roundly, and even sometimes loudly, enlig= htened.

And I note this discussion is forking off my original questi= on, which was basically
involving sane ways to come up with means of correctly routing or not
ro= uting various forms of non-single provider ipv6 connectivity.
=A0
There's no "problem" with the multiple
forms of addressing in IPv6.

=A0let's se= e:

ULA - this is the rough equivalent of rfc1918 address space in th= e 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 ne= twork rather than or in addition to ipv4, and haven't plugged into a pr= ovider 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 dn= s problem, unless there is some magical way for an address like fd03:024d:3= 2ac::/48 to make it from being internally generated to the users' eyeba= lls, perhaps via baudot code from the blinkenlights on the front...

Native, static: Hoo-ray! this is what we thought the world would get! O= ne static ip address range for all eternity. Until we realized that people = move, that offices have multiple locations, and that providers go under, an= d 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 th= ey may go away or change at any time. Worse, at least in the initial roll-o= uts I'm aware of, the address space may be as small as a single /64, an= d 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, th= ey 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...

Tered= o - on by default on windows...

Multicast... wouldn't it be grea= t if multicast worked? Wouldn't it be great if we knew how to make it j= ust 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 &= #39;ipv6 has no addressing problems' question did I not express properl= y?

The specific case I was merely trying to cope with was in refusin= g to route default routes
from the wrong place(s) and also try to ensure that that information got pu= shed closer to
each interior gateway.



The problem is with the ingress filtering policies of your upstream
ISPs.

*A* problem
=A0
=A0The clean solution i= s to use a single upstream ISP

So you are suggesting that everyone you might want to mesh w= ith to use a monopoly ISP?

=A0
>, or to u= se PI
space and make sure your upstreams accept packets sourced with your
address.

So you want to convince multiple providers to allow m= ultihoming?
=A0
If you cannot do that, put a full mesh of GRE tunnels between your
Internet gateways

Losing useful metrics and intr= oducing n complexity, as well as tunneling overhead.
=A0
, and put a bunch of source policy rules to make sure
each packet gets routed through the right gateway for its source
address. =A0Assuming the case of n upstreams, that's n gateways, and n-= 1
tunnels originating on each gateway. =A0Since there's no reason to have=
more than two upstreams (the cheap one and the reliable one), that's very reasonable.

Consider an apartment build= ing. You play games regularly with your downstairs neighbor,
he exchange= s files with the gal across the hall, she has a wireless link beaming down<= br> to her favorite coffee shop, the coffee shop has links to the vpn back to c= osta 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...
=A0

-- Juliusz


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



--
Dave T=E4ht
SKYPE: da= vetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
--0016e6d976e31de7e304b82f1990--