I'd like to test the water, so to say, on the scenario of running an aiccu-host that lives behind an existing NAT-box (that cannot be touched). Problem is that: - aiccu comes up, traffic is initiated from client, so it pokes a hole in the upstream NAT-box; - Once aiccu is up, IPv6 pings are sent, but they are initiated from the sixxs POPs. - If the UDP-hole in the NAT-box times out, then the tunnel is broken until a client-side packet pokes another hole in the upstream NAT-box. Until that time, it is impossible to access IPv6 hosts on the aiccu-side as the state on the upstream NAT-box blocks incoming aiccu packets. The easy way out is to have the tunnel send IPv6 ping packets, every 15 seconds or so. However, this does increase sixxs traffic so I like to bring this up to see what sixxs thinks about the extra traffic. This may be a configurable new option in aiccu? Upstream NAT-boxes, unfortunately, are a fact of life. Here in Serrekunda, I see upstream NAT on the hotel network, but the 3G network also only provides a NATed connection. Power outages cause temporary network outages (the core infra is power-protected but the hotel AP's are not, as they boot in a minute or so, but we see these several times per day as we switch from grid to gen and back several times per day. Also, there are upstream ISP issues (that I'm not going to describe here) that cause temp failures that are not easy to resolve (we're working with the telco's here but the environment here does have some unique challenges) I'd like to know what you think? Geert Jan AfNOG 2012, Serrekunda, Gambia