Excuse me if I find the claims of this vast "harm" ringing a little hollow. Exactly who am I supposed to be "harming" by choosing to deploy NAT ???
- My end users and my company board have had zero complaints regarding it. In fact, we generally get quite high marks for satisfaction with the services we deliver from both those groups. So it can't be them. - Application Developers who need to put in extra work to make their applications work with NAT?? Strange, I don't recall asking a single one of them to do that, EVER. Now if THEY choose to do that, I'm sure that they are not going to eat those costs but rather pass them along to me in the price of their product.... and if their product is worth running, I am certainly going to be willing to pay those costs. They could also choose NOT to build support for NAT into their products.... and then all the burden and costs associated with making that product work with NAT will fall upon me... not them. Again if their application is worth running then I will gladly meet that cost and burden. Strangely in the over 9 years my company has been in existence and I have been tasked with the responsibility of providing IT services for it there has never once been a single instance of this occurring. - Protocol Designers for whom NAT would provide a barrier to their Protocol working?? Again, I never asked anyone to design their Protocol to work with NAT. It's upto them to determine whether they WANT to deliver those services to NAT users.... no one is forcing them to do so. - Other end user who don't use NAT and feel like they need to pay an additional cost because application designers build in NAT support for those who use it?? I've NEVER told any outside entity what applications they must and must not purchase. By all means, go out and purchase an application that DOESN'T support NAT and save yourself some money. Can't find one? Well then your real argument is with the DEVELOPERS.... convince them not to build in NAT support and to lower the cost of their apps. - Outside application users who want to put packets across my network boundary but can't because I'm running NAT??? Sorry, but we've never advertised to ANYONE that we would automatically accept their packets regardless of the nature of them. Any promise of services or connectivity that we have made to anyone is VERY WELL DEFINED and doesn't include anything that NAT would break. Historically we've significantly exceeded those promises.... and the people with whom we have made them have expressed significant satisfaction with us in this area. Again, please inform me specifically who is being harmed by our choosing to deploy NAT and how? The only people I can see that would have a complaint are Developers who want to sell us applications that we don't want to buy and users who try to put packets across our networks that we don't want to receive. Forgive the analogy, but this is a little bit like people complaining that golf-clubs are more expensive because some people are left-handed and some are right-handed and a manufacturer has to supply both models if they want to reach the widest possible market. For those Application/Protocol developers who find it troublesome to design their products to work well with NAT the solution is simple.... DON'T. No one on the pro-NAT side is holding a gun to your heads and telling you that you must. Now if you want your product to be attractive to NAT users...then obviously putting in that support is important. However, I fail to see how that is any different then any other requirement a "consumer" of your product might give you in order for them to "purchase" it. Is the complaint here that you must include features that are attractive to your "consumers" rather then just those which you find convenient to build?? Forgive me if that fails to garner much sympathy from me. Christopher Engel -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mark Andrews Sent: Tuesday, November 03, 2009 11:33 PM To: Roger Marquis Cc: [email protected] Subject: [SPAM] - Re: [nat66] Necessity for NAT remains in IPv6 - Email has different SMTP TO: and MIME TO: fields in the email addresses In message <[email protected]>, Roger Marquis writes: > >> Mark Andrews wrote: > >>> NAT44 was a necessary evil as we had effectively run out IPv4 > >>> addresses. > >> > >> This is false. NAT was implemented long, long before there were > >> widesprea > d > >> concerns regarding the number of addresses. A larger reason for > >> NAT was that many of us were using non-routable addresses, as there > >> was (and still > >> is) no business case for any of our internal addresses to be publically > >> routable. > > > > Well then you don't need NAT then. > > > > If you need to get packets back to internal machines from external > > machines then yes those addresses were routed. You just routed them > > in translated form. > > That's an artifact of the (unforeseen at the time) transition from > application proxy-based firewalls to NAT-based firewalls. Still had > nothing to do with concerns regarding addresses availability, which > wouldn't attain critical mass for several years. And hosts didn't support more than one address on a interface and ... The reasons for using NAT back then have basically gone away. It really is just inertia and familiarity that keeps people asking for NAT despite all the harm its presense causes. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
