Valdis.Kletnieks@vt.edu writes:
> On Wed, 18 Jun 2003 16:06:08 PDT, Eric Rescorla said:
> > Melinda Shore <mshore@cisco.com> writes:
>
> > > Not really. For example, ftp as originally defined doesn't
> > > work through NATs, and no standard VoIP or multimedia
> > > conferencing protocol works through NAT.
> > None of these things worked real well through firewalls either,
> > which is sort of my point.
>
> There's a *crucial* distinction here:
>
> If it doesn't work through a firewall, it's because the firewall is doing
> what you ASKED it to do - block certain classes of connections.
>
> If it doesn't work through a NAT, it's because the NAT is FAILING to do what
> you asked it to do - allow transparent connections from boxes behind the NAT.
>
> Unless of course you're deploying NAT for some reason *OTHER* than
> transparent connections? Are you trying to get your money's worth because
> you paid for the extra-deluxe "works most of the time but breaks some apps"
> version?
This seems to me like a false dichotomy. If I were deploying a NAT
(which I didn't) there would be certain things I would care about
and others I didn't. If I'm already firewalling off these services,
why should I care if NAT blocks them?
> Or is the only reason you have NAT at all because you bought some vendor's
> "connection appliance in a box" that proceeded to NAT you regardless of your
> desires?
Why is it so hard for people here to believe that customers might
actually know what they want, even if you don't happen to think
it's a good idea?
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/