On 14-08-20 09:12 AM, Charles Musser wrote:
Thanks for the info. As it happens, I am also using a tunnel provided by HE.

I know - I could tell by the addresses  you provided :-).

My current thinking on how to do this is (in admittedly vague and incomplete terms) is: 
use a machine connected to the tunnel broker as a bridge. Other machines would connect to 
it and perform address auto configuration, using the prefix of the HE provided network. 
To accomplish this, the bridge machine would run the daemon that hands out these 
prefixes, which I think is called "rtadvd" Comments on this approach (or 
alternatives) are welcome.

Basically, yes. Although you have a "router" (does things with IP packets), not a "bridge" (does things with Ethernet frames) - that's a huge difference. I don't think I've ever relied on address autoconfig - it looks very nice in theory but has some limitations in practice. I would test everything using static IPs and static routes first, and then move on to rtadvd.

HE assigns two blocks of addresses with every tunnel - the point-to-point tunnel addresses and the "Routed IPv6 Prefixes". You want to use the IPv6 Tunnel Endpoints on the gif0 tunnel, which is presumably built on top of $external_if , and you want to use the Routed IPv6 Prefixes on $internal_if. Note that is perfectly valid to have public IPv6 addresses running on the same subnet as private (RFC1918) IPv4 addresses - IPv4 traffic gets NAT'd, IPv6 traffic merely gets routed.

Do beware that your pf ruleset must pass IPv6 traffic without NAT'ing it... I think this is the default now, not sure.

If you're like 99% of the IPv6-using population today, your router will probably become 2001:470:XXXX:XXXX::1/64 (on $internal_if), and clients on the internal network will then become 2001:470:XXXX:XXXX::2/64 to 2001:470:XXXX:XXXX::254/64. There may well be better ways, but that naive approach will work.

Oh, you'll have to enable net.inet6.ip6.forwarding on the router, I think it's off by default.

Finally, is this the place to discuss these kinds of network setup puzzles? I 
happen to be using OpenBSD, but this kind of task really is at the intersection 
of operating system specifics and the more general practice of network design.

Someone will tell you to go away, don't worry... The fact that you understand this makes answering you a lot more pleasant than the usual run-of-the-mill I deal with (elsewhere) where impossibly-bad network design somehow translates into "the firewall must be broken" when things don't work.

I suggest you try google - the second hit for "openbsd ipv6", at least for me, is a SANS Institute guide to setting up an IPv6 firewall using OpenBSD v3.0(!) which appears to mostly still be applicable. The docs for SixS aren't bad as long as you ignore the bits about their ~proprietary client software. Beware following guides that are too old - I see some old material referencing transition mechanisms (like FAITH - did anyone ever actually use that?), which probably aren't what you want to be looking at now.

--
-Adam Thompson
 athom...@athompso.net

Reply via email to