Hi Chris, 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. Even in cases where there is Sounds that you mainly think of unwanted P2P apps. The main problem is that NAT is an obstacle also for future transport protocols (e.g., DCCP, SCTP, and subsequent ones) and that you are stuck with whatever transport protocols the NAT supports. The only possibility to let future apps run smoothly is usually to buy in solutions like STUN/TURN that require additional components, making the whole architecture more complex. So to let arbitrary apps run you need NAT + STUN/TURN servers/relays and the control protocols (plus discovery delay etc.). That's IMHO much more complexity and requires more components in the e2e path that may fail or cause problems. > some application that might prove useful...usually work around can be > found... and in those cases it's upto the Network Admins to make > cost/benefit decisions about whether it makes more sense to find a > work around for that Application...or find a work around for the it's a question whether you want to make such "work arounds" part of the overall architecture. I don't. > benefits he perceives NAT provides. Furthermore, even if we choose > NAT today...there is nothing to say that if in future priorities > change we can't revisit that decision. Ultimately these are the type That's why we easily get rid off v4 NATs today... :-) > of choices that Network Admins are paid to make.... and trust me, if > we end up making poor ones we DO get held accountable for them. I think that NAT may have advantages, but there are other ways of achieving such goals. As Keith already said: NATs primary purpose is to limit address consumption. Probably other desired side effects are not covered too well in RFC4864 and several people want to see an update of it. But the cost of introducing NAT66 is the exclusion of future apps and protocols or the permanent buy-in of NAT traversal work arounds. > NAT is simply one type of tool which is available in our toolbox. > Thanks to the work people are doing with IPv6... there ARE alot more > options available in that toolbox. That's a good thing. However, just > because NAT isn't a very good tool for SOME situations doesn't mean > we should take it out of the tool box when it's still a perfectly > good tool for MANY situations (which it IS). It's like saying that If you consider the above costs, I don't think that its the right tool, especially NOT for security as already documented many times. > because we have all these fancy power tools available today...we > should all throw out our hammers when the hammer still works > perfectly well for many jobs. ...and perfectly breaks so many things. NAT66 may break less things than NATv4, but it still may break future transports and apps. Regards, Roland _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
