70 likes | 99 Views
Discover the complexities of NAT types and their impact on P2P applications, including stability, mapping behaviors, and diagnostic utilities. Explore challenges from standards like 3489 and how to optimize SIP endpoints while considering hairpinning and P2P application requirements.
E N D
NAT Diagnostics Derek MacDonald
Overview • NAT type discovery was defined in 3489 • Was not included in 3489bis as the discovery mechanism is not accurate • A reduced mechanism may be useful as a diagnostic tool • Could be useful to optimize P2P applications
Problems from 3489 • NAT behavior is not stable; NAT devices often get “worse” and change behavior under load or with time • Many corporate NAT/firewalls devices can become address and port dependent(mapping & filtering) • Consumer NATs seem to be stable • NAT binding timeouts are not stable
Utility for SIP endpoints • Can be used to detect if the NAT type requires a relay solution • Risky, as NAT type may change • Ice will move traffic off relay server • May save relay cost when communicating with non-ICE endpoints but will incur a risk that RTP traffic may stop flowing
Hairpinning • Detecting whether or not a NAT supports hairpinning seems to work • Could be used by endpoints to advertise a relay solution in the c line rather than th detected external IP address to give a better chance of connectivity • Not needed when ICE is supported
P2P Applications • P2P applications are interested in three NAT conditions: • Not behind a NAT/Endpoint Independent NAT(“supernode candidate”) • Address independent mapping & Address restricted filtering(keep-alives to all active peers) • Address dependent mapping & filtering • P2P applications would need to periodically rediscover
Port Dependent Filtering & P2P • Linux issues • Port preserving when same ports are used • Port dependent filtering NATs can not reach PDMADF NATs even with ICE; however elements behind an evil PDMADF must acquire relay to participate in the network