Common operational misconceptions

Mon Feb 20 02:06:40 UTC 2012

On Sun, 2012-02-19 at 19:09 -0600, Jimmy Hess wrote:
> For HTTP;  You put a device on that one IP that will accept each TCP
> connection,  await the SNI or Host  header from the client,   and then
> make/forward  the connection to a proper server for that hostname.

So you need an extra device to work around NAT. Or you have to build
extra smarts into existing devices to work around NAT. There is a
pattern here...

> For FTP,  send to a desired FTP server based on the login username or
> otherwise make a SRV record for the  _ftp  service for each hostname,
>  and   set aside a TCP port for each FTP service's control connection.

So NAT does indeed prevent the scenario Owen outlined.

It does not make sense to make that the application's fault. If you have
to build NAT-awareness (even indirectly, as in SRV-awareness) into every
application, then you've lost the game and it might be time to realise
that NAT is the problem, not all the applications.

> The problem is with the FTP protocol not supporting virtual hosting,
> though;  this missing FTP feature is not a NAT problem per se.

I'm not sure I agree with that, see above. And while virtual hosting may
be a Good Thing for various other reasons, it seems to me that if it is
required with NAT and is not required without NAT, then it is most
certainly "the fault of NAT" that it is required.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120220/c477b67d/attachment.sig>