--------------------------------------------------------------------------------------------
"Wrong. End users and board members typically don't understand what NATs are,
nor their effects on the network's ability to support applications. If they
want to run an app that doesn't work on your network, they blame the app, even
though the NATs in your network are what is screwing up the app.
Furthermore, end users and board members don't understand the degree to which
the widespread deployment of NATs is artificially raising the cost of deploying
new apps, and denying them useful new apps which might help employees in their
work and help their company's competitiveness.
Again, in IPv4, it's pretty much a moot point because address scarcity trumps
everything else. But that's not the case for IPv6."
--------------------------------------------------------------------------------------------
Correct, but what they DO understand is whether they are satisfied with the
services delivered to them or not...... whether their NEEDS are being
met......and whether the budget they pay for those services equals the VALUE
provided by them.
At the end of the day.... is that not the proof of any given approach?
If you really believe that stuff you said about NAT, then you pretty much don't
need to be afraid of NAT in IPv6. If what you say happens to be true then those
of us who choose to deploy it will be placing ourselves and our companies at a
competitive disadvantage....and we'll either "see the light" and
adapt/convert.... or we'll go the way of the dinosaurs.
Might the reality just happen to be that for a large portion of the community
NAT provides significantly more utility then any of these hypothetical new apps
that it is supposedly retarding?
I mean you DO realize that even in the IPv4 world there are organizations that
hold sufficient address space that they COULD assign every single device a
Public Address and they STILL choose to utilize private address space and
deploy NAT? That actually holds true for my company in one of it's environments.
Furthermore, you seem to have a very poor understanding of how corporate
environments actually work. If the end user wants to run an app and it isn't
working they don't "blame the app". What they do is goto corporate IT and say
"I'd like to run X, it's not working. Can you fix it for me please." It's upto
corporate IT to take it from there.
Furthermore, in corporate environments things don't normally even get to the
stage where NAT is breaking an end user application. That's because end users
don't generally go out and grab their own apps and start working with them on
their own in such environments. If that's happening to a significant degree in
a corporate environment... then it's got alot more serious problems than
whether NAT is breaking anything.
The way things typically go down in a corporate environment is...
1) End user has a need. They put a request through channels till it gets to
Corporate IT. The request reads something like "We have business need X. Here
are the requirements. Find us a solution." In rare cases the end user might
even suggest or indicate a preference for a particular application...but
usually not.
2) Corporate IT takes the request, makes sure that they have all the
requirements they need from the end user. They then start researching a
solution. They check this solution against...
- Company Security and Technology policies.
- Legal/Regulatory/Licensing considerations.
- Technology Standards, Compatibility & Interoperability
- Resource Allocation
- Budget (depending on who's budget it is being billed
against)
3) Corporate IT comes up with a suggested solution. They pass it back to the
business owner of the request to see if it meets their requirements.
4) Corporate IT tests the solution so they fully understand how to implement
and support it. Depending on what happens here we may go back to Step #2.
5) Corporate IT sets up a user acceptance test to ensure the solution is
acceptable to the business owner.
6) Corporate IT comes up with an implementation plan and everyone involved
signs off.
7) Solution is implemented and available to end users.
ANY application that has a significant impact on the organization is likely to
go through such a process. If it's a fairly trivial app and a trivial need then
those steps may be fairly informal/abbreviated but even still some sort of
iteration of it occurs.
NOTE by the time #7 rolls around and an end user has an application in their
hands it's generally very well understood whether NAT is likely to be breaking
it.
Christopher Engel
-----Original Message-----
From: Keith Moore [mailto:[email protected]]
Sent: Wednesday, November 04, 2009 12:38 PM
To: Chris Engel
Cc: 'Mark Andrews'; [email protected]
Subject: Re: [nat66] Necessity for NAT remains in IPv6
Chris Engel wrote:
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.
Wrong. End users and board members typically don't understand what NATs are,
nor their effects on the network's ability to support applications. If they
want to run an app that doesn't work on your network, they blame the app, even
though the NATs in your network are what is screwing up the app.
Furthermore, end users and board members don't understand the degree to which
the widespread deployment of NATs is artificially raising the cost of deploying
new apps, and denying them useful new apps which might help employees in their
work and help their company's competitiveness.
Again, in IPv4, it's pretty much a moot point because address scarcity trumps
everything else. But that's not the case for IPv6.
- 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.
Did you ask for internet telephony to work? Multi-party conferencing? Network
management?
What you fail to realize is that NAT affects every single application currently
used in the Internet. Many of them can continue to mostly work, with reduced
reliability, logging the wrong IP addresses, and various other operational
anomalies that users might not understand (and you might not understand
either). But lots of apps get changed in one way or another to deal with NAT.
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.
Since you're obviously in (deliberate) denial about those costs, it's clear you
aren't in a position to estimate them.
They could also choose NOT to build support for NAT into their
products....
and shrink their markets (at least in IPv4) to essentially zero. Yeah, that's
a real successful business strategy.
Keith
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
