|> 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.