the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?

Wed Apr 28 03:55:59 UTC 2010

Owen DeLong wrote:
> 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.
>   
Yes, there's additional development, but if NAT was more standardized 
(which it has a chance of being for IPv6, if we'd just stop arguing 
about whether or not it is going to happen... it'll happen, the question 
is whether or not there'll be a standard to follow) that development 
cost could be nearly a one-time library cost vs. custom code to deal 
with every situation and changing situations.
>   
>>>  
>>>       
>>>>> 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.
>   
Agreed.
> 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).
>   
No. Most NAT *doesn't* enforce a client-server model, it enforces a 
deliberate signaling model for establishing peer-to-peer communication, 
and allows open client-server communication (and most communication is, 
and will forever be, client-server). Assuming, again, that the NATs 
behave reasonably when trying to do peer-to-peer communication through 
them, which most (over 90% of what's deployed for IPv4) do. And *all* 
could, if there were standards people could code to. Which, again, for 
IPv6 there could be, if we'd stop claiming that NAT will never happen / 
is a bad idea and so shouldn't be standardized / etc.
>   
>>>  
>>>       
>>>>> 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".
>   
Again, such a lab would not be needed if NAT operation were codified in 
standards. Which could happen, if not for the vocal set who keeps 
arguing against them, even when there's 5+ good reasons for them, even 
in IPv6.
> 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.
>   
True, but that's essentially true for all software, and certainly true 
for all "web-based" software.
> 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.
>   
Really? There's still the name/service to address lookup problem. If the 
controlling entity goes away, you're again dead in the water. We're just 
lucky that some of those services (e.g., DNS) have a group who's agreed 
to run them in perpetuity as far as we can tell. If every root 
nameserver moved to a new IP address on a random whim tomorrow, most of 
these apps you talk about would stop working. No different than losing 
access to the aforementioned matchmaking service.
> 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.
>   
Some people want the matchmaking controlled by an entity other than the 
de facto one, actually. Lots of benefits to trying to register your 
highly-mobile computer in a peer-to-peer introduction system designed 
for that instead of in a DNS that isn't.

Matthew Kaufman

ps. In the spirit of disclosure, I should point out that I've shipped a 
peer-to-peer networking protocol that works through most NATs and which 
is almost certainly already installed on the computer you are using now.