> 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.
Yep- NAT showed up in Cisco IOS in the 11.2 version. I am definitely not an
expert on this subject, but a couple of things come to mind when running
through these posts:
NAT is almost always (or needs to be) configured in an overload state (or
PAT). If your NAT pool should become to small for your users (good rule of
10 users to 1 IP), you can always check the translation statistics & start
to move you pool accordingly. Unless I'm missing some sort of breach with
the occasional port table (when overload begins) it works quite well with
users heading to the Internet.
As far as the history of NAT, it's a band aide that offers some security
(sucks to trouble shoot @ times too). NAT is a selling tool today for home
users & ISP's that don't want to cough up addresses. As soon as IPV6 comes
online, NAT will offer almost no value add.
I was speaking to the fact that the only use for nat is
lack of v4 space. I'm not saying that other products don't provide
the security features that some people use NAT for.
Let me reprhase my inital statement, "In most cases i've seen
where someone is using NAT it's part of a security policy and not due
to lack of available address space".
>
> > I think you are obviously missing the point that people
> > use nat to prevent inbound connections as part of their security
> > measures.
>
> Every firewall I've ever seen allows you to do the exact same thing
> without NAT.
I was speaking to the fact that the only use for nat is
lack of v4 space. I'm not saying that other products don't provide
the security features that some people use NAT for.
NAPT (IETF terminology, PAT in Cisco-speak) requires a stateful packet inpection. Most firewalls also are stateful inspection packet devices. Not surprisingly, it's quite straightforward when implementing one, to implement the other. Thus most firewall appliances offer (though don't require) the use of NAT along with their other features.
Let me reprhase my inital statement, "In most cases i've seen
where someone is using NAT it's part of a security policy and not due
to lack of available address space".
By far the biggest-selling class of NAT boxes (in terms of units sold) appears to be the LinkSys and similar ~ $100 dual-ethernet boxes for home users. These boxes sit between the household network and the DSL or Cable modem. They do DHCP Client (and PPPoE where required) toward the provider, and act as DHCP server and NAT toward the home network. These are used PRIMARILY to get around address space issues. DSL and Cable vendors either don't provide more than one address, or provide limited numbers, available only via DHCP (a method incompatible with most firewall appliances anyway). So, I disagree with your statement that most are not used for address space reasons.
To be sure, there are DSL and Cable providers who actually understand how to route a subnet of real addresses to their customers. There are also a great many who don't or won't. These NAT/NAPT boxes are quite pervasive. Applications vendors wind up having to take notice if they're interested in the home user marketplace.
Not exactly, in your scenario you are counting on the firewall to block
hostile traffic destined for some ips. If they are Natted, it is more
work to compromise those stations.
Brian "Sonic" Whalen
Success = Preparation + Opportunity
Not exactly, in your scenario you are counting on the firewall to block
hostile traffic destined for some ips. If they are Natted, it is more
work to compromise those stations.
and if you change your name you are less likely to be mugged.
> Not exactly, in your scenario you are counting on the firewall to block
> hostile traffic destined for some ips. If they are Natted, it is more
> work to compromise those stations.
and if you change your name you are less likely to be mugged.
I think that most of this discussion has been about not just straight
address translation, but NAT with port translation. If you're using
address and port translation, the analogy goes more like "if you never
leave the house, but instead go through the same motions while sitting
in your house, while a robot performs your actions out in the real
world, you are less likely to be mugged." Which is true, if somewhat
of a dull existence...