Best practice for running 6to4 relays (was Re: 6to4 borkeness)

[Michael Taht]

Kevin Day wrote:
>
> On Mar 19, 2008, at 4:43 PM, Michael Taht wrote:
>> 1) I am curious as to what best practice would be to correctly setup a
>> 6to4 router for a small ISP, announcing the route is valid just for ips
>> within my network - and not incurring the entire weight of australia
>> trying to route through my gateway? (significant bandwidth charges here)
>>
>> There seems to be lots of documentation on the web on how to use 6to4 as
>> a client, but zero on how to setup a router. (or why not to try) Is it
>> even possible to do right? Conf files to setup on cisco gear or quagga,
>> explanations of how to avoid asymmetric routes, PMTU problems, etc
>> highly desired.
>>
>
> On our end, this is what we've got:
>
> Dedicated box doing nothing other than 6to4. It's a dual P3 866 Xeon,
> and it's pretty much got 99% idle time on it.
>
> This box uses Quagga to announce 192.88.99.0/24 and 2002::/16 to our
> core router. This way if the box dies, our announcements get withdrawn.
A quagga conf file (example or real) would be helpful to look at...

I note that everybody doing this seems utterly reliant on BGP, in terms
of distributing the anycast address to the world. In the inside the
smaller (wireless) ISP case, BGP is not in use. I wonder what will
happen (router trafficwise) if I use another protocol... or don't use
one at all. what additional traffic would dns udp over ipv6 generate...

I assume you are doing BGP announcements to the core router from quagga.

Similarly, I assume your core router filters out bogus announcements of
other 6to4 routers (for example, someone as crazy as I am, inside your
network, mistakenly announcing they have 6to4 with a better metric than
you do...

(conf files help with understanding, and wasn't planning on BGP internally)
> Another box acts as a 6to4 client, and checks the operation of the
> relay every 60 seconds. It makes sure it's properly
> encapsulating/decapsulating data, and at least 7 of 10 "important" v6
> sites are reachable. If only 7 are, it pages our NOC mail alias. If 6
> or less are reachable for more than a few minutes it kills the relay's
> BGP announcements until we look at what's wrong.
Sounds reasonable. ping6 in nagios/shellscript/something I can whip up
fast, and a content checker, via http to a v6 server outside the local
net. Somewhere. Multiple wheres, actually.

I found a nifty little ipv6 netcat w/multicast over  at
http://mnc.googlecode.com/svn/trunk which might be interesting.

My principal fears involve multicast, actually, but more on that in a
later missive.
> We're decently well connected (10 of the 43 paths on route-views for
> 192.88.99.0/24 go to us), but total traffic is still really pretty small. 
I am discussing this with some people at a major australian ISP (who
seem to be really hung up on supporting business clients only and on
supplying tunnels rather than 6to4), and a wireless ISP (that doesn't
care how it works, just so that traffic is optimal), in addition to the
olpc stuff.... As best as I can tell, there is a better business case to
"sell tunnels", but I think the egg part of this chicken is to "provide
access and the benefit to people that want it to 'just work'"... and
6to4 addresses do that better... and round and round we go.
> The occasional burst over 100mbps often enough to justify a GigE port
> for this, but average use for our Chicago relay is less than 10mbps.
> Average use for our Amsterdam relay is less than 30mbps.
I look forward to the results of your ipv6experiment! :)
>
> You can do the same for a local network, just don't let those
> announcements leave your AS.
>
Totally understand.
> -- Kevin