So you decide to have a play with 6to4 tunnelling, and everything works OK. That's good, except you may have just opened a huge hole in your firewall(s) :-(
I have a standalone firewall which runs Linux and uses Netfilter to provide firewalling. The machines behind the firewall also run Linux and use Netfilter. Early in the iptables rules I have the fairly common:iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
rule, to allow inbound traffic on my outbound-initiated connections.
Now, you have 6to4 tunnelling working, and you point your web browser to http://ipv6.google.com/, where this hostname resolves to an IPv6 address (but not a 2002:: address, so you're relying on a 6to4 gateway - which we'll assume is ::22.214.171.124). And you see the web page. Great.
Now look at the connection tracker for your firewalls. You'll see
an entry which says Allow inbound protocol 41 traffic from
126.96.36.199 (and pass it to this local machine, if appropriate).
unknown 41 587 src=192.168.1.1 dst=188.8.131.52 packets=111 bytes=15578 src=184.108.40.206 dst=192.168.1.1 packets=122 bytes=136328 mark=0 secmark=0 use=2
I see this on the local machine and the standalone firewall.
At this point, you've opened a hole in your firewall which allows through ANY 6to4 traffic from the 220.127.116.11 gateway - i.e. anyone running 6to4, so they could telnet or ssh to your machine, connect to your MTA, etc.
A similar issue exists when talking to 2002:: addresses, except this time you're only wide open to any 6to4 traffic from that host.
You need to put some rules into ip6tables in order to stop unsolicited traffic.
Incidently, it's not just Linux which suffers from this. In fact, where I used to work we used this technique to enable us to bypass all the corporate security systems in order to connect to our desktop machines from home: setup 6to4 tunnelling, add a cronjob to ping6 a machine at home every few minutes, and you've opened up a hole through which you can use any IPv6 application to connect to work.