current 6to4 state

[Brian E Carpenter]

On 12/11/2012 06:35, Phil Pennock wrote:
> On 2012-11-12 at 12:49 +0700, Ivan Shmakov wrote:
>>>>>>> Steinar H Gunderson <sesse at google.com> 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 192.88.99.1 servers.

The point is that a server which is plagued by incoming 6to4-originated
traffic (i.e. with a 2002:: prefix) can choose to improve the user
experience by running a local return-relay:

http://tools.ietf.org/html/rfc6343#section-4.5

It's much better if the end user doesn't try 6to4 in the first place,
but the server has no control over that.

   Brian

> 
> 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.
> 
> So:
> 
>  * 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
> network.)
> 
> 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.
> 
> -Phil
>