By nature, a tunnel between a 6to4 router and a 6to4 relay router is insecure. The following types of security problems are inherent in such a tunnel:
Though 6to4 relay routers do encapsulate and decapsulate packets, these routers do not check the data that is contained within the packets.
Address spoofing is a major issue on tunnels to a 6to4 relay router. For incoming traffic, the 6to4 router is unable to match the IPv4 address of the relay router with the IPv6 address of the source. Therefore, the address of the IPv6 host can easily be spoofed. The address of the 6to4 relay router can also be spoofed.
By default, no trusted mechanism exists between 6to4 routers and 6to4 relay routers. Thus, a 6to4 router cannot identify whether the 6to4 relay router is to be trusted or even if it is a legitimate 6to4 relay router. A trusted relationship between the 6to4 site and the IPv6 destination must exist. Otherwise, both sites leave themselves open to possible attacks.
These problems and other security issues that are inherent with 6to4 relay routers are explained in RFC 3964, Security Considerations for 6to4. See also RFC 6343, Advisory Guidelines for 6to4 Deployment for updated information about using 6to4.
Generally, you should consider enabling support for 6to4 relay routers for the following reasons only:
Your 6to4 site intends to communicate with a private, trusted IPv6 network. For example, you might enable 6to4 relay router support on a campus network that consists of isolated 6to4 sites and native IPv6 sites.
Your 6to4 site has a compelling business reason to communicate with certain native IPv6 hosts.
You have implemented the checks and trust models that are suggested in Security Considerations for 6to4 and Advisory Guidelines for 6to4 Deployment..