Chris Engel wrote: to decide. In many cases, it DOESN'T harm their organizations environments at all.... because the applications they would be missing are NOT the "best applications to get work done" or meet the organizations technology goals.... or because NAT friendly alternatives exist for the ones that do.
One example that's often cited as being a NAT issue is SIP(/STUN/TURN). The real issue here, however, is SIP's embedding of a network layer address in the application data. This convoluted authentication mechanism, and ISO 7 layer model breakage, is the problem, not NAT. SIP is an old, old protocol onto which many kitchen sink-like 'features' have piggybacked. Far less reengineering would be required to use modern protocols like IAX in place of SIP than to get rid of NAT (which isn't even a possibility anyhow). Protocols like DCCP and SCTP which do not implement TCP-like statefulness are also cited as NAT issues but their real issue is statefulness. It doesn't matter whether a firewall uses NAT or not, it still has to keep the state of these non-TCP streams for security, and the use of NAT without firewalling is so rare (usually limited to server load balancing) it can be considered a non-issue. Any time you have an edge device keeping a state table it is easy to implement NAT on top of that. Since letting these protocols through the firewall without statefulness is not an option, and any time there is statefulness NAT can be implemented easily, there is no NAT issue here. Despite all the vague and unsubstantiated claims of 'NAT issues' we are still waiting for an example that actually holds water. Until then you are safe in assuming that financial interests, not technical issues, are blocking the implementation of NAT in IPv6. Roger Marquis _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
