On Apr 27, 2010, at 11:49 AM, Matthew Kaufman wrote:
Owen DeLong wrote:
On Apr 27, 2010, at 10:48 AM, Matthew Kaufman wrote:
Andy Davidson wrote:
On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote:
Did you use Yahoo IM, AIM, or Skype?
Yes, yes, and yes. Works fine.
What about every other service/protocol that users use today, and might be invented tomorrow ? Do & will they all work with NAT ?
Anyone inventing a new service/protocol that doesn't work with NAT isn't planning on success.
Respectfully, I disagree. There are many possible innovations that are available in a NAT-less world and it is desirable to get to that point rather than hamper future innovation with this obsolete baggage.
I would argue that every one of those innovations, if even passably useful, can also be implemented in a NAT-full world.
Perhaps, but, often at significant additional code, development time, QA resources and other costs. Also, often at a degraded level requiring a non-NAT'd third-party broker to intermediate between any two NAT'd parties attempting to trade information.
Do many others work as well or act reliably through NAT ?
Yes.
In reality, it's more like some yes, some not so much.
== Some designed to work properly in the face of NAT, some ignored reality at their peril.
We can agree to disagree about this. The reality is that there are cool things you can do with peer to peer networking that simply aren't possible in an enforced client-server model. NAT enforces a client-server model and permanently and irrevocably relegates some administrative domains to the client role. This is an unfair disadvantage to the users within those domains when it is not by the choice of the administrator (and NAT in IPv4 so far, often is not).
Will it stop or hamper the innovation of new services on the internet ?
Hasn't so far.
Here I have to call BS... I know of a number of cases where it has.
Ok, you called it... so where's the list of such services that haven't materialized as a result of NAT?
Haven't materialized, for one, is an attempt to redefine the question. Note that the original question included "hamper". I would argue that the cost of maintaining a NAT compatibility lab and the QA staff to use it is a sufficient burden to call it "hamper". For the ones that did not materialize, however, I am at an unfortunate disadvantage in the argument. I can tell you that I know of at least 5 such cases. However, I cannot reveal the details because I am under NDA to the companies that were developing these products. I can tell you that in 3 of the 5 cases, adapting them to cope with a NAT world would have required the company to run an external service in perpetuity (or at least so long as the application would function, no server, no function) in order to do the match-making between clients that could not directly reach each-other. I guess a good analogy is this: In a NAT world, you have only matchmaking services and all of your ability to meet potential mates is strictly controlled through these matchmaking services. There are many services available independent of each other, and, each has its own limitations, biases, and quirks. However, you cannot meet potential mates without involving at least one matchmaker. In a NAT-Free world, you have the ability to use a matchmaking service if you like, but, you also have the ability to meet potential mates at bars, in the grocery store, on the street, in restaurants, through chance meetings, introductions by a friend, or even at work. It is possible that if you never knew it was possible to meet potential mates in all of these other ways, you would happily deal with a vast number of matchmaking services hoping to find a useful result. On the other hand, if you were to ask the average person who has experienced the latter scenario if they would be willing to limit their choices to only using a dating service, my guess would be that most people would reject the idea outright. Owen