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

[Bernhard Schmidt]

Hi,

>> a) it is still worth a discussion whether 6to4 relays should source 
>> IPv4 packets from 192.88.99.1 (pro: does not break with stateful 
>> firewalls) or some provider unicast address (pro: easier to track what 
>> 6to4 relay was used on the way back, anycast addresses should not be 
>> used as source for anything). I chose the latter, plus you can force 
>> your traffic to go through this gateway by using this address instead 
>> of 192.88.99.1 as default gw. If you want to source from 192.88.99.1, 
>> make that address the main address on Lo2002.
> 
> I get far more "YOUR RELAY IS BROKEN?!?!!!!!!!" emails if we use our 
> unicast address than if we use 192.88.99.1 as the source. Unfortunate 
> because of the loss of troubleshooting help, but I believe making it 
> work at all is more important. 

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.

> 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).

Regards,
Bernhard