Username: Password:

Client-side IPv6 pings to keep upstream NAT-boxes open..
[nl] Geert Jan de Groot on Friday, 11 May 2012 12:15:26
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
Client-side IPv6 pings to keep upstream NAT-boxes open..
[ch] Jeroen Massar SixXS Staff on Friday, 11 May 2012 12:37:23
Use AYIYA, it was made for this, it crosses the NAT and sends heartbeats too to keep the NAT state alive, and even if it would change, it is not a big issue as every packet, including the heartbeat, updates the PoPs knowledge of what IP/port it needs to use.
Client-side IPv6 pings to keep upstream NAT-boxes open..
[nl] Geert Jan de Groot on Sunday, 13 May 2012 01:04:54
I'm using AYIYA, but I'm not a complete solution I'm afraid: the heartbeat pings are sent from the POP, not the client. If the upstream NAT box looses UDP state (because of power, or because the time-out is shorter than the heartbeat cycle - I've seen both) then the heartbeat pings of the POP never reach the client, until the client opens up another path by initiating IPv6 traffic. Until that time, the IPv6 network is disconnected. Hence, I'd suggest to have the client send heartbeat instead of (or in addition to) the POP, or at least provision for that. But this might generate extra traffic and hence my question. Geert Jan
Client-side IPv6 pings to keep upstream NAT-boxes open..
[ch] Jeroen Massar SixXS Staff on Sunday, 13 May 2012 01:10:54
I'm using AYIYA, but I'm not a complete solution I'm afraid: the heartbeat pings are sent from the POP, not the client.
That is a different thing. The PoP performs latency checks and for that it indeed sends ICMPv6 packets from the PoP to the endpoint of the tunnel. What I am talking about is the heartbeat that is built in the AYIYA protocol, that does not use ICMPv6, but a AYIYA next-header of 'none'. It is one of the primary foundations of AYIYA and what makes it 'special' compared to other VPN-alike protocols.

Please note Posting is only allowed when you are logged in.

Not logged in.
©2001-2014 SixXS - IPv6 Deployment & Tunnel Broker