To amuse myself, and because I have two linux boxes on all the time, I decided to try to make my NAT'ed SixXS heartbeat tunnel automatically failover to the other linux box if one were to go down. Using UCARP and following this example I was able to set up a virtual IPv4 IP that would successfully failover between nodes. I set my router to forward protocol 41 (6in4) to the virtual IP. Then I removed the scripts that start my aiccu and radvd daemons and put the startup commands in scripts that would start and stop them when the local node became the master node. Per the linked example I used arping to notify other ethernet nodes that the virtual IP changed hardware addresses. And the software side of things worked wonderfully. The network side was spotty. Within my NAT things went mostly as expected, but sometimes I wouldn't be able to access the tunnel. I could see pings go out but not come back. It seemed to work after a while, but not reliably, and the SixXS Tunnel Statistics showed I was losing all of my pings most of the time. I finally checked my router's security log, and it was blocking tons of outbound protocol 41 (tunnel) packets because of duplicate NAT mappings. So my router vehemently objected to my moving the tunnel endpoint around like that. I tried tweaking a number of things but couldn't make it work. I had to go back to the way it was. Ultimately I think my problem had nothing to do with IPv6 or tunneling. I think trying to run any type of failover clustering behind my NAT would fail similarly. (Maybe if I spoofed the hardware address and ensured the service used the virtual IP instead of the node IP...but I've already spent too many hours on this.) UCARP worked quite well and was easy to use, though. I thought that would be the hard part. I had a different version, different kernel and different distribution on each box, so I'm even further impressed with it. One of my boxes has OpenVZ, and I originally tried to put the gateway in a VE but was unable to get aiccu to create a tun/tap tunnel even with the dev nodes created and the proper (I think) capabilities configured for the VE. Here is some of the code snippets I used if anyone's intereted: Ubuntu Hardy Heron server edition has a newer ifupdown which allows some slick options in /etc/network/interfaces. This one has a bridge and OpenVZ, but apparently neither of those was the problem: My other box was Debian Etch, and the snazzy options above didn't work with its older version of ifupdown, but this following snippet worked fine as the other node for the above snippet: The ucarp up/down scripts I made are the same on both boxes. I commented them heavily for my own benefit. /etc/ucarp/vip-2-up.sh: /etc/ucarp/vip-2-down.sh: Note: My script manually assigns the virtual IP. The ucarp docs say that if I use the ucarp-upscript and ucarp-downscript entries I have to assign the IP myself, otherwise ifupdown would handle it. It worked out, anwyay, since my Etch box needed the manual scripts and I had a few extra steps to take, anyway. I am moving the prefix::1 address back and forth, too, just for those two nodes. I found I had to manually assign them a gateway. At least I think I did. Some tweaking of sysctl might have eliminated the need for that.