Best practice for running 6to4 relays (was Re: 6to4 borkeness)

[Kevin Day]

On Mar 19, 2008, at 6:08 PM, Bernhard Schmidt wrote:

> I've just set that accordingly on my side, I'll try to compare  
> traffic levels in a couple of days. Did not change anything on the  
> first sight.
>
> Note that pMTU discovery for the IPv4 path is impossible (!)  
> regardless of the capabilities of your gateway implementation if you  
> use 192.88.99.1 as source (as ICMP messages will probably be  
> delivered somewhere else), so you should set the IPv6 MTU to the  
> minimum allowed (1280, which makes it 1320 in IPv4). There are  
> enough strange links out there with MTUs somewhere between 1400 and  
> 1500 (VPN, PPPoE, PPPoL2TP) which can and will break if you just use  
> the default 1480 bytes.
>

Yep, we keep the MTU locked at 1280.

>> But, we accept 6to4 packets destined to either address. If you  
>> configure a 6to4 client to use our unicast address, the replies  
>> come back sourced from our unicast address.
>
> Is that some Cisco knob or own implementation? Because I'm not sure  
> how this would work. Packets in either direction are not linked (I'm  
> not aware of any 6to4 gateway keeping state for that, it would have  
> to save the local address that received the packet for any /48).
>

Sorry, I phrased that badly. I don't mean the return packets from  
other hosts, but packets sourced on my end.

If you are using 192.88.99.1 as your 6to4 relay, and the relay  
generates an ICMP back to you, it uses 192.88.99.1. If you're using  
our unicast address, the unicast address is used in that case.

For v6 packets coming into the relay destined for 2002::/16,  
everything going out the v4 side is 192.88.99.1, since as you stated,  
we can't track state.

This is all being done on a BSD box too, I'm not sure how Cisco  
handles that specific case.

-- Kevin