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 (ka...@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
signature.asc
Description: This is a digitally signed message part
