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/