current 6to4 state

[Mike Jones]

On 12 November 2012 06:35, Phil Pennock <ipv6-ops+phil at spodhuis.org> wrote:
<snip>
>  * user sends IPv6 packet to their default route
>  * local router wraps in 6to4 IPv4 wrapper, sends to 6to4 anycast node
>  * hopefully some 6to4 anycast node receives it; if not, then _all_ 6to4
>    traffic for the user is broken, not just this site
>  * that node unwraps, sends IPv6 packet to the target server
>  ----
>  * target server generates IPv6 reply packet, source of their public
>    (non-6to4) address, target of the user's 6to4 address
>  * before the packet leaves the server, it goes through the stf0
>    interface and is wrapped in IPv4
>  * that IPv4 packet is sent directly back to the user's local router

With a source address of your server

>  * which unwraps the 6to4 and injects the inner IPv6 frame into the
>    local network
>
> All subject to firewall rules.  (You had better hope your home router is
> source-filtering 6to4 payload packets to not have addresses on your home
> network.)

such as the firewall rule blocking 6to4 return traffic not sourced
from 192.88.99.1

Yes, this is probably a broken configuration. However it's one that
i've heard second hand do exist and afaik all the anycast instances
use that source IP address so it's not a problem, however it is worth
noting that such a client would be able to reach your server before
but not after you added the local encapsulation.

Personally I think the tradeoff is probably worth it, the number of
clients that filter non-192.88.99.1 packets is probably smaller than
the number of broken return paths, and is at least consistent. But
worth being aware of the potential problem if you have to debug some
connectivity issue with a 6to4 user at 2am (although "6to4 is broken
and doesn't work" might be a better answer to give at 2am).

- Mike