On 2010-09-22 at 12:07 -0400, Edward Ned Harvey wrote:
> OSX Snow Leopard: Network Preferences, add 6to4.)
On an IPv6 mailing-list, someone with a beta of the next point-fix for
Snow Leopard notes that they've even fixed the 6to4 support so that it
won't turn on if you're on RFC1918 address-space and so that it's not
preferred to IPv4.
> In a 6to4 address, 16 bits are arbitrarily selected by the device.
Somewhat.
> So I logically conclude: If your little linksys or whatever router supports
> 6to4, and it can distribute IPv6 to the autoconfigure clients on your LAN,
> that means you don't even need to do *any* thing to your
> windows/mac/whatever laptops etc. Just enable the checkbox for 6to4 in your
> little router, and voila, you have IPv6 running on your LAN.
>
>
>
> Anybody doing anything like this in practice, or am I just talking theory at
> this point? Unfortunately, I can't test it myself, because I'm one of the
> saps who doesn't get a real IP address from their ISP.
The good point of 6to4 is that it doesn't require static tunnels. The
bad point is the awkwardness in debugging. The packets take radically
different paths in each direction.
Eg, my Apple Airport has 6to4 support and static tunnel support (and
these days will even configure up a static tunnel even if the WAN
address is dynamically assigned). I use IPv6 extensively. I used an
he.net tunnel for a while, but encountered frequent TCP connection
resets on my long-lived SSH connections. So I switched to a SixXS
tunnel and encountered weird problems with MTU when talking to some
sites, no matter what I did to MTU configuration of the tunnel (perhaps
the changes weren't "taking"? It's hard to tell). So I switched back
to 6to4.
Having switched back to 6to4, the MTU problems disappeared and I could
reach git.exim.org fine, but I could no longer reach my own colobox over
IPv6! So, I went in (IPv4) and checked with tcpdump and could see the
icmp6 ping packets being received and replies being sent, but those
never arrived back at my end. traceroute6 showed the packets hitting an
unreachable address in Telia's network.
The issue is that public 6to4 relies upon ISPs operating gateways and
then advertising prefixes standard anycast addresses (RFC 3068). Some
ISPs provide this prefix to their own customers, some announce them
publicly as a service to others. But some of those who announce out
don't care to fix problems, or apparently bother with monitoring ...
When I last played with 6to4, I was able to get the ISP to fix a
problem. This time around, I reported the problem to Telia on the 6th,
and again on the 12th and there has been no response. In the meantime,
my colo provider has admin-dropped the prefix learnt from Telia at my
request and so now IPv6 traffic being sent back to 6to4 addresses works
again.
See how much of a pain that would be to debug if you didn't understand
routing fairly well?
In practice, I've stuck with 6to4. My home ISP (Comcast, Business
class) now provides 6to4 to their own customers, which is an excellent
move! I encourage any ISP with native IPv6 transit considering their
deployment approaches to do this: it's cheap and it can't make things
worse, it will only improve things for your own customers. This means
that one leg is very reliable. The return-path ...
I can't solve return-path problems for the general case in the face of
apathetic carrier ISPs who pollute public resources by announcing
prefixes they don't actually handle and don't bother responding to mails
reporting the issue. I can deal with it for the cases I care about.
I can also recommend that if you have native IPv6 on a server box but
don't control the network enough to put in a 6to4 relay, then it's
worth configuring up 6to4 locally, so that you're not dependent upon the
RFC 3068 publicly routed addresses. You do *NOT* need to provide
service on 2002::/16 addresses and it's very definitely a BAD idea to do
so. But if you configure up the interface and insert the 2002::/16
prefix into the host routing table, then you can make sure that the
return traffic is sent in IPv4 from your box back to their box and
improve stability. For me, this actually increases the latency of IPv6
back up to IPv4 levels, since I'm back to the same routes which are
subject to the market forces of the IPv4 market instead of the more
optimal routing over the more friendly IPv6 peering community that still
exists.
For FreeBSD, this is as simple as setting in /etc/rc.conf:
stf_interface_ipv4addr="$ipv4.of.your.link"
and opening a firewall hole for the traffic if you're filtering. Since
you only need to allow 6to4 *outbound*, as you never advertise your own
6to4 address in DNS or bind services to it, that can be fairly safe.
Might break if you let apps bind to wildcard addresses and they are
using UDP to respond and so they choose the 2002::/16 address and the
client then talks back to that. So don't do that.
pass on $main_if inet proto ipv6 from (self) to any \
label "6to4 traffic out"
Moral of this story: if at all possible, operate your own 6to4 relays,
or have 6to4 outbound-only support on your servers, and you'll
interoperate better during what is likely to be a protracted
provisioning period before end-sites predominantly have native IPv6.
You don't have to like it, you can push the native as much as possible,
but pragmatically it makes your life much easier, by helping you control
part of the picture and reducing headaches.
Regards,
-Phil
_______________________________________________
Tech mailing list
Tech@lopsa.org
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
