current 6to4 state

Phil Pennock ipv6-ops+phil at
Mon Nov 12 07:35:57 CET 2012

On 2012-11-12 at 12:49 +0700, Ivan Shmakov wrote:
> >>>>> Steinar H Gunderson <sesse at> writes:
>  > It's simple; if you wish, you can add a 6to4 decapsulation on every
>  > server if you wish.
> 	Well, my question was about 6to4 /encapsulation/, actually.
> 	AIUI, there's likely to be just a single 6to4 relay
> 	decapsulating the packets sent from 6to4 hosts to the IPv6 nodes
> 	proper.  However, there'll be a lot of such relays on the
> 	reverse direction, and thus it's the broken /encapsulating/
> 	relay case that'd likely be much harder to troubleshoot.

I think that Steinar mis-spoke and what he meant was that you can add a
6to4 _encapsulation_ on every server, since decapsulation is provided by
the servers.

For instance, on FreeBSD, setting stf_interface_ipv4addr in /etc/rc.conf
to be your public IP will bring up stf0 at boot.  With nothing _routing_
to that IP, you're not going to receive inbound traffic to it, and you
can packet-filter to ensure you're not receiving traffic _to_ that IP
too, if you want.  But it will be used for return traffic.


 * 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
 * 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

This means that you can run a server and know that even if the end-user
is unfortunate enough to be stuck using 6to4, then as long as their
packets can reach you, and as long as IPv4 is reliable, you can get your
packets back by removing a component from the return path.  If you do
this, and the user's 6to4 connection to you breaks, then most likely
_all_ of their 6to4 is broken and you won't even see the IPv6 packets
from them in the first place.


More information about the ipv6-ops mailing list