rob@76: When implementing NAT traversal we need to consider the following:
rob@76: ( all quotes taken from [1] )
rob@76: 
rob@76: - NATs require some kind of periodic message to keep their port mappings
rob@76:     current "some NATs have timeouts as short as 20 seconds"
rob@76: 
rob@76:     "Unfortunately, many NATs associate UDP idle timers with individual UDP
rob@76:     sessions defined by a particular pair of endpoints, so sending keep-alives
rob@76:     on one session will not keep other sessions active even if all the
rob@76:     sessions originate from the same private endpoint. Instead of sending
rob@76:     keep-alives on many different P2P sessions, applications can avoid
rob@76:     excessive keep-alive traffic by detecting when a UDP session no longer
rob@76:     works, and re-running the original hole punching procedure again ``on demand.''
rob@76:         
rob@76: - if UDP traffic is blocked by a firewall we might want to tunnel via TCP to
rob@76:     a machine on the open internet. in this case we need to perform STUN protocol
rob@76:     properly to analyze which machines are on the open internet (this info could
rob@76:     be sent to peers with the status messages).
rob@76: 
rob@76: - might be better to transmit hashes of passwords rather than the passwords
rob@76:     themselves to keep users who enter semi-important passwords from
rob@76:     accidentally transmitting them as plain text.
rob@76: 
rob@76: - the udp port used to punch in a hole to communicate with other users
rob@76:     could be selected dynamically rather than being fixed by the user
rob@76:     "Finally, NAT implementations exist that consistently translate the
rob@76:     client's private endpoint as long as only one client behind the NAT
rob@76:     is using a particular private port number, but switch to symmetric
rob@76:     NAT or even worse behaviors if two or more clients with different IP
rob@76:     addresses on the private network try to communicate through the NAT
rob@76:     from the same private port number"
rob@76:     which means we should at least offer the option of clients manually
rob@76:     setting their outbound ports to different values to avoid collissions
rob@76:     behind the same NAT which exhibits the above behavior.
rob@76: 
rob@76: 
rob@76: - skype tries to connect via port80 and https ports if it can't make a
rob@76:     connection in other ways.
rob@76:         
rob@76: --
rob@76:     "A few poorly behaved NATs are known to scan the body of UDP datagrams
rob@76:     for 4-byte fields that look like IP addresses, and translate them as
rob@76:     they would the IP address fields in the IP header. To be robust against
rob@76:     such behavior, applications may wish to obfuscate IP addresses in
rob@76:     messages bodies slightly, for example by transmitting the one's
rob@76:     complement of the IP address instead of the IP address itself. Of
rob@76:     course, if the application is encrypting its messages, then this
rob@76:     behavior is not likely to be a problem."
rob@76: 
rob@76: - because sending requests to ports behind a nat can send the wrong request
rob@76:     to the wrong machine, we need to make sure to handle this robustly
rob@76:     in clients
rob@76: 
rob@76: [1] Bryan Ford, Pyda Srisuresh, Dan Kegel, "Peer-to-Peer Communication Across
rob@76:     Network Address Translators", http://www.brynosaurus.com/pub/net/p2pnat/