RE: arguments against NAT?
I'm not arguing about that, it is delaying things indeed. However I wonder which kind of instant messaging you are referring to, as all the ones I've seen work fine through NAT. Peer-to-peer CUSeeMe stopped working for me when I installed a NAT box at home. Now I can only do peer-to-peer CUSeeMe on a single computer for which I've installed the appropriate port redirects in the NAT box. Sure, server-based CUSeeMe still works on all the computers, but peer-to-peer now only works on the one. Any protocol where you have to receive an incoming connection on a fixed port, and want to do so on multiple machines, just doesn't work when a NAT is in place. /jeff
RE: arguments against NAT?
Armando, Michel Py wrote: I'm not arguing about that, it is delaying things indeed. However I wonder which kind of instant messaging you are referring to, as all the ones I've seen work fine through NAT. Armando L. Caro Jr. Yahoo and AOL (I have never used MSN). Sure, you can do normal chatting, but once you extend into the other features such as file transfer, voice, and webcam... things break. In many enterprise environments, this would be a feature not a bug. There are some webcams that are definitely inappropriate in a business setup; given the lack of good enterprise content filtering solutions for IM, if NAT does break IM webcams I don't have a problem with it. As of file transfer, it does not bother me either as like a lot of other network administrators I have a problem with users sharing their office computer files with anyone unknown on the net. For voice there's always that thing called the telephone that has the advantage to work all the time with anybody and can be logged. Michel.
Re: arguments against NAT?
On Wed, 03 Dec 2003 09:15:07 PST, Michel Py said: In many enterprise environments, this would be a feature not a bug. There are some webcams that are definitely inappropriate in a business setup; given the lack of good enterprise content filtering solutions for IM, if NAT does break IM webcams I don't have a problem with it. That's backwards. That kind of webcam is often *not* behind a NAT at the source end, so can be contacted. What breaks is that *your* user can't have a videoconferencing solution that your business partners can contact. If your user is running that kind of webcam from their office, you have bigger management issues than a NAT. :) For voice there's always that thing called the telephone that has the advantage to work all the time with anybody and can be logged. Ever notice that this works a *lot* better when each user has their own phone number, rather than one number that rings at the receptionist's desk and may or may not get transferred to the actual person? There's a lesson there. pgp0.pgp Description: PGP signature
Re: arguments against NAT?
Michel Py wrote: Joe Touch wrote: Since we've been lacking a similar non-NAT solution, we (ISI) built one called TetherNet, as posted earlier: http://www.isi.edu/tethernet What is this beside a box that setups a tunnel? What's the difference with: http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_e xample09186a00801982ae.shtml The same difference, in principle, between DHCP and setting the IP address yourself. The details of which are in the ISI web page above. FWIW, the seriousness of the impediments (Michael Py) are felt wherever NATs are deployed. Yeah right. That's why there are millions of NAT sites and they all have serious impediments. There are millions of Compaq computers sold; all that run Windows (the vast majority) rely on a local web server to manage Compaq software updates. But the people behind NATs don't know that. They just don't get the updates. There are other cases where things just silently fail, and people go out and buy alternatives that work, or live without. You deem this, in other mail, a 'security feature'; I deem it a bug. Ignorance is bliss, but only when it's not expensive and/or frustrating. Your other post to Melinda was closer to the primary issue, IMO - whether we can create an alternative which is as easy to use. The whole point of my post is that this can be done. Our solution may not be the best or the only one, but it proves (by example) that NATs aren't the only way to automated subnets, and that there is a way to undo the effects of NATs if - or when - those effects are finally noticed. Joe
RE: arguments against NAT?
On Tue, 2 Dec 2003, Michel Py wrote: I'm not arguing about that, it is delaying things indeed. However I wonder which kind of instant messaging you are referring to, as all the ones I've seen work fine through NAT. Yahoo and AOL (I have never used MSN). Sure, you can do normal chatting, but once you extend into the other features such as file transfer, voice, and webcam... things break. You can get _some_ subset of features to work if you have control of the NAT, but otherwise your stuck. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net |University of Delaware | 0-- --0
RE: arguments against NAT?
On Wed, 3 Dec 2003, Michel Py wrote: Michel Py wrote: I'm not arguing about that, it is delaying things indeed. However I wonder which kind of instant messaging you are referring to, as all the ones I've seen work fine through NAT. Armando L. Caro Jr. Yahoo and AOL (I have never used MSN). Sure, you can do normal chatting, but once you extend into the other features such as file transfer, voice, and webcam... things break. In many enterprise environments, this would be a feature not a bug. Maybe, but that's not the point. Not everyone who is forced to be behind a NAT is in an enterprise environment. Plus, if enterprise environments want to implement this feature, firewalls work fine. There are some webcams that are definitely inappropriate in a business setup; Says who? Each business is different. given the lack of good enterprise content filtering solutions for IM, if NAT does break IM webcams I don't have a problem with it. You don't have a problem with it, but others do. Plus, why are firewalls not sufficient for blocking IM? As of file transfer, it does not bother me either as like a lot of other network administrators I have a problem with users sharing their office computer files with anyone unknown on the net. Again, YOU are ok with file transfer breaking... not everyone. For voice there's always that thing called the telephone that has the advantage to work all the time with anybody and can be logged. Oh, your right... so all the time that IM vendors invested in implementing voice chat was truly a waste, because there is absolutely NO demand for it. And all those users that currently are using voice chat as we speak/type have simply missed the fact that they could pick up the phone to pay more for their conversation. (As I finish this reply, I realize it was a waste of my time... but now that it's written, I'll send it anyway.) ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net |University of Delaware | 0-- --0
Re: arguments against NAT?
In many enterprise environments, this would be a feature not a bug. There are some webcams that are definitely inappropriate in a business setup; given the lack of good enterprise content filtering solutions for IM, if NAT does break IM webcams I don't have a problem with it. As of file transfer, it does not bother me either as like a lot of other network administrators I have a problem with users sharing their office computer files with anyone unknown on the net. For voice there's always that thing called the telephone that has the advantage to work all the How nice for you to be able to determine what everyone else should be able to run on their networks.
Re: arguments against NAT?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Keith Moore wrote: |In many enterprise environments, this would be a feature not a bug. |There are some webcams that are definitely inappropriate in a business |setup; given the lack of good enterprise content filtering solutions for |IM, if NAT does break IM webcams I don't have a problem with it. | | |As of |file transfer, it does not bother me either as like a lot of other |network administrators I have a problem with users sharing their office |computer files with anyone unknown on the net. | | |For voice there's always |that thing called the telephone that has the advantage to work all the | | | How nice for you to be able to determine what everyone else should be able | to run on their networks. | Yeah. The level of clueloss boggles the mind. MVH leifj -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/zlIj8Jx8FtbMZncRAuK0AKC9pb1scpTssHJtSbWuwM/AV/zCugCeIK6N 9XAfBN0fpbRH8AZGIiSs4/A= =Rutg -END PGP SIGNATURE-
Re: arguments against NAT?
Michel Py wrote: [..] As of file transfer, it does not bother me either as like a lot of other network administrators I have a problem with users sharing their office computer files with anyone unknown on the net. I trust you frisk all employees for CD-R/RWs, floppies and USB sticks on their way home each evening too cheers, gja
arguments against NAT?
A new sysadmin has recently joined the company where I work (I am a software engineer and part-time sysadmin). As he's the only full-time sysadmin here, the network now falls under his purview. Today he showed me his plans for reorganisation of the network, and they involve introducing NAT on a big scale. His main arguments in favour of NAT are security (which I debunked), address shortage (which we don't have), and administrative convenience (which he never explained enough for me to see). I've argued strongly against NAT, but he's one of those people who seem to be willing to accept arbitrary amounts of pain (we don't need to use [protocols that put IP addresses in payload], timeouts aren't a problem). I'm now pointing him at some relevant RFCs. My question for the list is is there a web page or other document anywhere that comprehensively states the case against NAT? -zefram
Re: arguments against NAT?
Zefram writes: My question for the list is is there a web page or other document anywhere that comprehensively states the case against NAT? If your new administrator is of the type who fixes things that aren't broken, it may be the admininistrator that needs replacement, not the network configuration. As you point out, you aren't short on address space (the primary reason for NAT). Security is not a problem for NAT, since any good netadmin is going to know how to block and route traffic with routers, firewalls, proxies, etc., to avoid problems. Too bad if it is time-consuming ... that's what he is being paid for, so he can't complain. Admininstrative convenience is not a reason, either. If admininstration were that convenient, his position would be redundant. In any case, restructuring an entire network so that one can spend more time playing Doom in one's cube is a very poor justification for the operation. NAT has obvious disadvantages. The Internet is not designed to address multiple machines with one IP address, and lots of things will break when NAT is in place. Incoming machine-specific traffic is the major problem. Chat and instant messaging services will fail, and there is no way to get them to work with NAT. Streaming services may fail as well. NAT can compromise point-to-point security. Overall it's a clever but nasty kludge that I cannot see implementing if it isn't required. It works for SOHO configurations with just one public IP address and the like, but it seems like a very poor idea for any organization that doesn't have an address shortage.
Re: arguments against NAT?
Yeah, but this was the point. Where is the community consensus document that says all this? Spencer - Original Message - From: Anthony G. Atkielski [EMAIL PROTECTED] To: IETF Discussion [EMAIL PROTECTED] Sent: Tuesday, December 02, 2003 6:55 AM Subject: Re: arguments against NAT? Zefram writes: My question for the list is is there a web page or other document anywhere that comprehensively states the case against NAT? If your new administrator is of the type who fixes things that aren't broken, it may be the admininistrator that needs replacement, not the network configuration. As you point out, you aren't short on address space (the primary reason for NAT). Security is not a problem for NAT, since any good netadmin is going to know how to block and route traffic with routers, firewalls, proxies, etc., to avoid problems. Too bad if it is time-consuming ... that's what he is being paid for, so he can't complain. Admininstrative convenience is not a reason, either. If admininstration were that convenient, his position would be redundant. In any case, restructuring an entire network so that one can spend more time playing Doom in one's cube is a very poor justification for the operation. NAT has obvious disadvantages. The Internet is not designed to address multiple machines with one IP address, and lots of things will break when NAT is in place. Incoming machine-specific traffic is the major problem. Chat and instant messaging services will fail, and there is no way to get them to work with NAT. Streaming services may fail as well. NAT can compromise point-to-point security. Overall it's a clever but nasty kludge that I cannot see implementing if it isn't required. It works for SOHO configurations with just one public IP address and the like, but it seems like a very poor idea for any organization that doesn't have an address shortage. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
Re: arguments against NAT?
And, to follow up on my own posting (sigh), RFC 3235 and 3027 are Informational... we have no STD, and no BCP, that come up when you search for NAT or Network Address Translator, so... perhaps there is no community consensus document that says what the community consensus appears to be, and the best thing to do is to Google NAT end-to-end and leave the result as an exercise for the reader? Sigh. Spencer Yeah, but this was the point. Where is the community consensus document that says all this? Spencer
Re: arguments against NAT?
On Tuesday, December 2, 2003, at 08:22 AM, Spencer Dawkins wrote:
Yeah, but this was the point. Where is the community consensus
document that says all this?
3235 goes into some of it, albeit from an application perspective.
2993 does as well, but at three years old it's already slightly
outdated. One thing that hasn't been discussed and needs to be is
that NAT workarounds have become a growth industry and they introduce
a bunch of new security and other problems.
I'm not sure if you're arguing that there should be a comprehensive
document presenting the technical problems introduced by NATs. I
suspect there should be, although frankly this is one particular
area where there's a clear and growing divide between this community
and the network administrator community (particularly enterprise
and residential). We've known about these problems for a very
long time and the argument that these problems are a serious impediment
to network {stability,robustness,whathaveyou} have not been accepted
by the people who deploy real networks.
At this point I really don't think it's the case that we haven't
made the argument well, or at sufficient volume. People who put NATs
in their networks are usually responding to immediate or perceived
needs, and I think it's frequently, if not mostly, the case that they
understand what they're doing and simply don't have the luxury of
being able to worry about the longer-term implications. In that
context our arguments are sometimes perceived as condescending and
out-of-touch. Because of that it becomes difficult for the NATs
cause problems position to become sufficiently widely accepted to
overcome the conventional wisdom that NATs provide security, etc.
I imagine we're going to be running into a similar situation with the
mad use of tunnels in the not-too-distant future.
Melinda
Re: arguments against NAT?
Spencer Dawkins wrote: Yeah, but this was the point. Where is the community consensus document that says all this? RFC 2993 is the closest thing I could find to what I want, and it's rather good (thanks Tony), so it's at the top of the reading list I've sent to the new sysadmin. I'll be interested to see his reaction to it. Looks like disaster may be averted in my case: the responsible manager, in a rare fit of technical eptitude, has spotted that the new sysadmin is interfering in things that already work. Strangely, address allocation is just about the only thing on this network that *isn't* broken. -zefram
Re: arguments against NAT?
I've argued strongly against NAT, but he's one of those people who seem to be willing to accept arbitrary amounts of pain (we don't need to use [protocols that put IP addresses in payload], timeouts aren't a problem). I'm now pointing him at some relevant RFCs. My question for the list is is there a web page or other document anywhere that comprehensively states the case against NAT? This organization makes its opinions known through not only standards but RFCs that have been reviewed by IETF working groups, the community, and the IESG. RFC 2663 is the one you want. See in particular scaling issues, multihoming, DNS, and IPsec, just to name a few. Eliot
Re[2]: arguments against NAT?
Spencer Dawkins writes: ... perhaps there is no community consensus document that says what the community consensus appears to be ... I don't believe there is any consensus. I'm among those who don't like NAT, considering it only an occasional, necessary evil.
RE: arguments against NAT?
Melinda Shore wrote:
although frankly this is one particular area where
there's a clear and growing divide between this
community and the network administrator community
(particularly enterprise and residential).
Because this community has long ignored real problems and followed the
lead of protocol fanatics or rhetoricians that for the sake of technical
elegance design protocols and architectures that look real nice on paper
and don't solve real world issues.
We've known about these problems for a very long time
and the argument that these problems are a serious
impediment to network {stability,robustness,whathaveyou}
have not been accepted by the people who deploy real
networks.
The seriousness of the impediments is grossly overblown in this
community. In theory, practice and theory are the same. In practice,
they're not. If NAT was that bad, nobody would use it. NAT is bad, but
not bad enough to disappear.
I imagine we're going to be running into a similar
situation with the mad use of tunnels in the
not-too-distant future.
The market as always will pick the solution that is the best compromise.
Just like NAT, saying that tunnels are bad is as efficient as going duck
hunting with an accordion. If this community does not want to see mad
use of tunnels, it must provide a better solution instead of whining. It
must design protocols and architectures with users in mind, not to
please software developers.
Saying that people that deploy real networks should not use NAT because
NAT creates problems is the same as saying that people should not drive
cars because they pollute. Yes they do, and I'm driving one anyway.
Michel.
Re: arguments against NAT?
On Tuesday, December 2, 2003, at 10:44 AM, Michel Py wrote: Because this community has long ignored real problems and followed the lead of protocol fanatics or rhetoricians that for the sake of technical elegance design protocols and architectures that look real nice on paper and don't solve real world issues. I don't think that's quite fair. The problems we're seeing from NATs - and they're considerable - really are the ones to be expected as a consequence of the violation of first principles. We know that NAT is contributing quite heavily to delaying the more widespread deployment of VoIP, internet conferencing, and some instant messaging. There's absolutely no question about that. The market as always will pick the solution that is the best compromise. Several Nobel prizes in economics have recently been given to people whose careers have been devoted to demonstrating that that's not the case (particularly around how the lack of availability of information to all parties interferes with market efficiency). I really don't see how arguing about the goodness or badness of NAT is useful. NAT causes problem - observed problems. The question that's in front of us at the moment is the organizational response. I think we've done a reasonable job of documenting the issues. Spencer points out that none of these documents are BCPs, but to be honest I think that the typical consumer of IETF documents isn't aware of or doesn't care about the document status other than yes-it's-an-RFC/no-it's-not-an-RFC. My concern is more with how we respond to the growing divide between us and the people who deploy things we recognize are bad, when those things dominate the market. We need to keep churning out documents, and I hope we can at least try to think about coming up with alternative technologies that are more idiomatic. For example, midcom and RSIP and STUN have their flaws, heaven knows, but at least they push addressing information back out to the endpoints. That, I think, is far better than much of what's been going on in industry around stateful inspection and its various adaptations, proxying, and so on. Really, the question here isn't whether or not NATs are good or bad (and I hope we can avoid having that discussion yet again), but rather whether or not we're going to be able to come up with a useful response to unfortunate things happening in the field. Melinda
Re: arguments against NAT?
Zefram, Our take on why NATs are bad is at: http://dsonline.computer.org/0207/departments/wp4icon.htm And our method for undoing what a NAT does, called TetherNet is at: http://www.isi.edu/tethernet and paper about it is at: http://www.isi.edu/touch/pubs/discex03-tethernet/ (Contact me if you want to try one out.) It's been difficult to understand how the IETF has for several years worked to develop NAT standards - notably since NATs themselves break what few standards the Internet has (RFCs 1122 1123 - aka STD-3 and RFC 1812 - aka STD-4). As I've said in many WGs, NAT standards are 'laws for the lawless'. As others have observed, this is hardly community consensus, however. Joe Zefram wrote: A new sysadmin has recently joined the company where I work (I am a software engineer and part-time sysadmin). As he's the only full-time sysadmin here, the network now falls under his purview. Today he showed me his plans for reorganisation of the network, and they involve introducing NAT on a big scale. His main arguments in favour of NAT are security (which I debunked), address shortage (which we don't have), and administrative convenience (which he never explained enough for me to see). I've argued strongly against NAT, but he's one of those people who seem to be willing to accept arbitrary amounts of pain (we don't need to use [protocols that put IP addresses in payload], timeouts aren't a problem). I'm now pointing him at some relevant RFCs. My question for the list is is there a web page or other document anywhere that comprehensively states the case against NAT? -zefram ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
Re: arguments against NAT?
... I've argued strongly against NAT, but he's one of those people who seem to be willing to accept arbitrary amounts of pain (we don't need to use [protocols that put IP addresses in payload], how about DNS? two of the extra years that got tacked onto the decade of DNSSEC were due specifically to middleboxes who intercept/regenerate DNS transactions. this has also slowed the deployment of EDNS. anyone who deploys NAT is freezing their DNS protocol competence at today's level, which is not only bad for the people behind that particular NAT but will be bad for the standards people who are trying to evolve the DNS. (or did folks generally just not know that DNS includes IP addresses in its payload, and that a successful NAT box has to intercept/regenerate DNS, and that NAT boxes who don't understand EDNS just cause timeouts due to improper end-to-end signalling of feature levels, and that this regeneration activity has been absolutely fatal to several proposed DNSSEC designs?) ... I'm now pointing him at some relevant RFCs. My question for the list is is there a web page or other document anywhere that comprehensively states the case against NAT? eliot's answer to this part was so good that it bears repeating: This organization makes its opinions known through not only standards but RFCs that have been reviewed by IETF working groups, the community, and the IESG. RFC 2663 is the one you want. See in particular scaling issues, multihoming, DNS, and IPsec, just to name a few. my own summary of the issues is that the internet's architecture has a number of constraints and that if we want to continue to scale the design we all have to operate within those constraints. operating outside of the generally accepted constraints, or adding new constraints that aren't generally accepted (or even generally known) makes evolution just stop. (this issue came up during the verisign sitefinder debates, and i'd like to thank klensin and bellovin for clarifying my thoughts on this topic.) -- Paul Vixie
Re: arguments against NAT? - what breaks
Anthony G. Atkielski wrote: NAT has obvious disadvantages. ... ... Chat and instant messaging services will fail, and there is no way to get them to work with NAT. So far I have not been able to get chat or instant messages services to fail because of NAT. (Not that I am saying that NAT is valuable or a problem) Perhaps it is more accurate to say that some NAT implementations break chat and IM? Streaming services may fail as well. -- Doug Royer | http://INET-Consulting.com ---|- [EMAIL PROTECTED] | Office: (208)520-4044 http://Royer.com/People/Doug |Fax: (866)594-8574 | Cell: (208)520-4044 We Do Standards - You Need Standards smime.p7s Description: S/MIME Cryptographic Signature
Re: arguments against NAT? - what breaks
Doug Royer wrote: Anthony G. Atkielski wrote: NAT has obvious disadvantages. ... ... Chat and instant messaging services will fail, and there is no way to get them to work with NAT. So far I have not been able to get chat or instant messages services to fail because of NAT. (Not that I am saying that NAT is valuable or a problem) Perhaps it is more accurate to say that some NAT implementations break chat and IM? Some NAT implementations break (your favorite protocol here). The problem isn't whether a particular NAT breaks a particular protocol; the larger problem is what to do when you have a protocol you need and you're behind a NAT you can't control. Streaming services may fail as well. Agreed. Joe
Re: arguments against NAT?
Melinda Shore wrote:
...
I'm not sure if you're arguing that there should be a comprehensive
document presenting the technical problems introduced by NATs. I
suspect there should be, although frankly this is one particular
area where there's a clear and growing divide between this community
and the network administrator community (particularly enterprise
and residential). We've known about these problems for a very
long time and the argument that these problems are a serious impediment
to network {stability,robustness,whathaveyou} have not been accepted
by the people who deploy real networks.
At this point I really don't think it's the case that we haven't
made the argument well, or at sufficient volume. People who put NATs
in their networks are usually responding to immediate or perceived
needs, and I think it's frequently, if not mostly, the case that they
understand what they're doing and simply don't have the luxury of
being able to worry about the longer-term implications. In that
context our arguments are sometimes perceived as condescending and
out-of-touch. Because of that it becomes difficult for the NATs
cause problems position to become sufficiently widely accepted to
overcome the conventional wisdom that NATs provide security, etc.
I imagine we're going to be running into a similar situation with the
mad use of tunnels in the not-too-distant future.
Melinda
One of the arguments in favor of NATs has been efficacy - we have them,
they're cheap, and when they work they work well and with no configuration.
Since we've been lacking a similar non-NAT solution, we (ISI) built one
called TetherNet, as posted earlier:
http://www.isi.edu/tethernet
The other argument in favor of NATs is that they already exist, so we
have to live with them. TetherNet takes a contrary approach, undoing the
NAT-ing instead.
FWIW, the seriousness of the impediments (Michael Py) are felt
wherever NATs are deployed. Things break - in various NATs, these
'things' include L2TP to secure email access, VoIP/teleconferencing,
FTP, and many services that rely on servers on the local machine (e.g.,
Compaq's automated software update system). Other, less serious problems
include stalled or very slow web and telnet connections. These breakages
are often misattributed to host, router or DNS misconfiguration, OS
glitches, or the network being down. Those who don't know better just
live with a flakey or slow network.
Joe
Re: arguments against NAT?
My question for the list is is there a web page or other document anywhere that comprehensively states the case against NAT? Because until recently there was a widespread belief that we were stuck with NAT and might as well make the best of it, and that we couldn't make the best of it if we were criticizing it. Also there was a naive hope that NAT's problems could somehow be solved and that the internet could function without a coherent address space. Finally there was a NAT working group that worked hard to legitimize NAT (its charter notwithstanding), and the existence of this working group precluded any constructive effort to discourage NAT.
RE: arguments against NAT?
Melinda,
Melinda Shore wrote:
The problems we're seeing from NATs - and they're considerable
It depends of the situation; don't generalize, the reality of numbers is
against you. The number of sites where NAT works just fine is orders of
magnitude greater than the number of sites where it causes more than
minor inconveniences. We're the IETF; we don't design the Internet for
the select few that have issues with NAT, we design it for everyone.
As examples: at home, I don't have a problem with NAT (and I do have an
overkill setup). In most organizations, the argument that NAT breaks
H.323 is moot, because H.323 traffic is internal voice only that is not
being NATted. There are many cases where yes NAT does break things, but
the point I am trying to make is that in the _millions_ of cases where
NAT is deployed and works, it has been deployed because its
inconveniences are far less than its advantages. The reason NAT is
deployed is the failure of this community to provide a better solution.
- really are the ones to be expected as a consequence of the
violation of first principles.
With end-to-end being on top of that list, I agree.
We know that NAT is contributing quite heavily to
delaying the more widespread deployment of VoIP,
internet conferencing, and some instant messaging.
There's absolutely no question about that.
I'm not arguing about that, it is delaying things indeed. However I
wonder which kind of instant messaging you are referring to, as all the
ones I've seen work fine through NAT.
I will also make the point that in the case of VoIP deployment, if NAT
is one of the things that is slowing it down, it's not the only one.
Frankly, at 2.5c / min for long distance calls, no VoIP
hardware/configuration and no QOS worries, in many cases POTS or
voice-grade circuits still are winners. Organizations do not deploy VoIP
because it's cool, organizations deploy VoIP because they want to see an
ROI on it; as of today in many cases this ROI is not there, NAT or not.
The market as always will pick the solution that is
the best compromise.
Several Nobel prizes in economics have recently been
given to people whose careers have been devoted to
demonstrating that that's not the case
I have the greatest respect to Economics Nobel prize winners but I have
never met one that has half of a clue on what it takes to operate an
enterprise network on a daily basis. There is a difference between the
market and what the market would/could be if this or that. How many
of these Nobel prizes understand the relationship between NAT and
renumbering (opposed to the obvious and moot save IP addresses and
security ones)?
I really don't see how arguing about the goodness or
badness of NAT is useful.
Me neither. NAT is bad, period.
I think we've done a reasonable job of documenting the
issues. Spencer points out that none of these documents
are BCPs, but to be honest I think that the typical
consumer of IETF documents isn't aware of or doesn't
care about the document status other than
yes-it's-an-RFC/no-it's-not-an-RFC.
Agree, not to mention the fact that the typical network administrator
does not read RFCs. We can document all we want; the influence on market
behavior is very limited.
My concern is more with how we respond to the growing
divide between us and the people who deploy things we
recognize are bad, when those things dominate the market.
By providing these people (the market) with a better alternative (which
is not easy) and my stopping to think _only_ about the sacro-saint
principles.
Earlier, you were concerned about the proliferation of tunnels. Why do
people use tunnels? Partly to run over them protocols that do not cross
NAT.
However, instead of admitting that people will run non-nattable
protocols over NAT no matter what, we keep designing non-nattable
protocols. At the end of the food chain, the network administrator, not
being able to find an IETF solution to his/her problems (that BTW needs
to be solved in days or weeks, not years) hands the task of making
things work to Karl Kludge and Jerry Rig, with the results we know.
I apologize for using a simplistic example, and I do acknowledge that
what I am about to suggest is not as simple as I might make it sound.
However, think about the following: if
{your_favorite_VoIP_protocol_here} crossed NAT nicely, not only it would
have been _much more_ deployed by now, but also it would not generate
this mesh of tunnels from hell that you are concerned about.
Really, the question here isn't whether or not NATs
are good or bad (and I hope we can avoid having that
discussion yet again),
We're not having it.
but rather whether or not we're going to be able to
come up with a useful response to unfortunate things
happening in the field.
A good beginning would be to listen to what people that actually _are_
in the field implementing real networks have to say about it.
Millions have implemented NAT. Contrary to popular
RE: arguments against NAT?
Joe Touch wrote: Since we've been lacking a similar non-NAT solution, we (ISI) built one called TetherNet, as posted earlier: http://www.isi.edu/tethernet What is this beside a box that setups a tunnel? What's the difference with: http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_e xample09186a00801982ae.shtml FWIW, the seriousness of the impediments (Michael Py) are felt wherever NATs are deployed. Yeah right. That's why there are millions of NAT sites and they all have serious impediments. Michel.
Re: arguments against NAT?
Michel Py; Melinda Shore wrote: The problems we're seeing from NATs - and they're considerable It depends of the situation; don't generalize, the reality of numbers is against you. The number of sites where NAT works just fine is orders of magnitude greater than the number of sites where it causes more than minor inconveniences. How can you say the number of sites where NAT works just fine? Have you operated such sites with and without NAT and compared the result by asking all the users? Or, does it just mean that network operators they operate their network just fine? We're the IETF; we don't design the Internet for the select few that have issues with NAT, we design it for everyone. Design what? IP network beyond NAT is not part of the Internet. I have the greatest respect to Economics Nobel prize winners but I have never met one that has half of a clue on what it takes to operate an enterprise network on a daily basis. There is a difference between the market and what the market would/could be if this or that. How many of these Nobel prizes understand the relationship between NAT and renumbering (opposed to the obvious and moot save IP addresses and security ones)? The only thing economists should observe is that ISP service with a lot of IP addresses is charged a lot more than that with a single IP address. The difference reflects the real world evaluation on the cost of NAT. Masataka Ohta
