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

[Matthew Kaufman <matthew () matthew at>]

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.