Home page logo
/

nanog logo nanog mailing list archives

RE: Where NAT disenfranchises the end-user ...
From: Roeland Meyer <rmeyer () mhsc com>
Date: Thu, 6 Sep 2001 22:29:21 -0700


|> From: Eric A. Hall [mailto:ehall () ehsco com]
|> Sent: Thursday, September 06, 2001 9:49 PM

|> > "Charles Sprickman" <spork () inch com>
|> 
|> > NAT has it's place, and we have many happy customers that are quite
|> > pleased with their NAT'd connections; some simple, some fancy.
|> 
|> NATs are a band-aid.

ip_masq started out as a cheap way to cheat ISPs that wouldn't allocate IP
addrs to dial-up users (home users have no need for a LAN?), or wanted to
charge an arm'n'leg for every IP addr. This irked the Linux community
sufficiently that they wrote a "cure". Unfortunately, the popularity of the
"cure" superceded the need.

|> > What irks me more than NAT are crappy protocols like FTP 
|> and H.323 that
|> > make too many assumptions about how much of my machine I 
|> am willing to
|> > expose in order to communicate using these protocols.
|> 
|> FTP was designed for ARPANET, H.323 was designed to work 
|> over ANY packet
|> network. Neither of them were designed for TCP/IP in particular.

FTP has well outlived it's usefullness. There are better alternatives. It
was a good experiment...on how we shouldn't do some things. NDAs stop me
from commenting about H.323. Just know that every SuSE Linux 7.2 distro
comes with www.openh323.org and www.opengatekeeper.org software, complete
with instructions on interfacing it with NetMeeting3. No, it won't work
across NAT boundaries.

|> They don't break the end-to-end design principles though. 
|> Neither do network games, chat tools, and other 
|> peer-to-peer protocols that run in elected-server
|> or server-to-server modes.

Damn, more NDA problems <g>. It is sufficient to state that one of the
challenges facing p2p projects is presented by the large NAT population.
Actually, dynamic IP isn't so good either. But, we are getting around that
with LDAP directories. The real problems arise when two clients report the
same RFC1918 address to the directory. If both are behind a single NAT'd IP
then it gets really fun.

|> The fact is that I can write an Internet-compliant 
|> application in about two minutes that will break every 
|> NAT ever sold, simply because they don't have a
|> proxy for the protocol. NATs violate fundamental Internet 
|> principles. They were broken from the start.

Agreed. It is all fine and dandy to say what developers should and shouldn't
do. Rarely, are those practicing such refined methodology, actually writing
the code or paying for same. Market needs drive business requirements, which
drives code, which drives operations, which *may* drive more market needs.
NAT was an answer to a market need that operations wasn't fulfilling. The
pent-up market demand for multi-homeing may drive solutions that the
operations community may not like.

Guys, this is easy. Start accepting prefixes out to /24 like you are already
getting paid to do. Then ARIN can start selling /24s and matching ASNs, like
they should. Yes, you might lose some revenue from IP addr sales, but the
alternatives might be less desireable.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]