![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Folks, Hammers are inteded to solve a certain problem space. So, we should not use hammer to solve every problem we encounter, (or) ban hammers altogeher because they do not solve all problems. Now, the reality check. NATs donot respect end node ownership of IP entities (IP-Addr, port # etc). Thats how they accomplish address conservation and obviate address renumbering. This lack of IP address sactity clearly violates the assmptions made by a large number of problems. So, NAT is not the hammer to use. Make the problems go away (or) show clearly superior solutions to solve the problems. Then, may be, we wont need the NAT hammer. I dont have a problem with that. There are efforts going on in the IETF to precisely do the above. That is great and I am all for it. Soon, the market place will tell us when it is time to retire or replace the NAT hammers. Until then, let us not engage in NAT flaming (or) overtly push NATs to be a save-all solution. To that end, I encourage you to participate in in the NAT working group, addressing precisely these issues. There is a draft to desctibe NAT complications (i.e., limitations of NAT problem space) and your input to draft authors/editors is most welcome. The NAT WG also has a draft to define NAT friendly criteria that new applications need to adhere to for acceptability into NAT problem space. If you have some input you could provide, Please do. Lastly, there is an IAB draft describing architectural issues with NAT. Once again, do send in your comments to the draft authors. Thanks. regards, suresh ===== __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.