Re: tlug: It works!

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Jim" == Jim Tittsler <jwt-tlug@example.com> writes:

    >> What I'm thinking is that when a web server on the net gets a
    >> request from 192.168.1.2 how will it know where to send the
    >> reply to? Or am I misunderstanding something (again :-)?

    Jim> The server will have rewritten the address to its real
    Jim> address, when the reply comes back, it puts the private
    Jim> address of the requesting machine back.

To be just a little more detailed than Jim:

Remember that TCP/IP is a multiplexing technology.  There are two
independent[1] address spaces, one for addressing machines (the "IP
address"), a 32-bit number (that will be expanded 128 bits in IPv6, go
to the meeting on Saturday for a full explanation), and one for the
service (the "port number"), a 16-bit number.  Many (about 1000) of
those 16 bit numbers have been registered for use as publically known
"listening" ports where servers wait for connections.  Outgoing ports
rarely need be prespecified.  In fact, this would make life very
difficult for servers designed to handle multiple connections at once;
it is the sending, or "reply-to," port that distinguishes different
processes on the same machine.

Now, all internet information arrives as packets; on an ethernet,
packets that do not have your address on them are discarded[2]
(actually, left in the "ether" for the correct machine to pick up), on
PPP those packets are preselected by your gateway.  Those that do have
your address on them are sorted by port number, and processes that
have been assigned a given "reply-to" port number will have those
packets placed in their incoming queue.  Packets with port numbers
assigned to no process are thrown away.

What IP masquerading does, then, is provide services created
on-the-fly called not "ftp," but "ftp from machine A that I masquerade
for".  These services are created, dynamically assigned a port, and
registered in the TCP/IP table of "ports in use".  The remote host
then sends replies to what it sees as an arbitrary port, but the
masquerade gateway recognizes it as a special masquerade port, looks
it up in a table, and relays to the host and port specified there.
Note that since both the originating host and the masquerade host are
assigning "reply-to" ports dynamically, the port on the originating
host will normally differ from that on the masquerade host.

This is similar to what a gateway to a dynamically allocated IP
address does, except that from the point of view of the Internet that
address is permanent but the host it addresses changes.  In
masquerading, the address is constant, but the host (and service)
varies from the point of view of the Internet.

Note that this means that the masquerading gateway can only provide
_servers_ on well-known ports from _one_ of the hosts it masquerades
for, usually itself.  (Ie, you could theoretically remap port 23 to a
telnet server on a different machine that you masquerade for, so that
maintenance to the masquerade gateway would have to come from the
console.  But who'd want to?)  However, if you want to you could
theoretically provide preassigned ports on the gateway to pass through
to masqueraded hosts.  Eg, you could assign the 100 ports 8000-8099 to
http servers.  These would of course be private, but "private HTTP
servers" used a lot even without masquerading for various reasons.  (I
think this would require an extension to current masquerading
technology, though.)

Footnotes: 
[1]  The exact word is "orthogonal," but TJH has prohibited its use.

[2]  OK, pedants, please note that I carefully did _not_ write "IP
address."

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences        Tel/fax: +1 (298) 53-5091
---------------------------------------------------------------
Next Meeting: 10 October, 12:30 Tokyo Station Yaesu central gate
Featuring the IMASY Eng. Team on "IPv6 - The Next Generation IP"
Next Nomikai: 20 November, 19:30  Tengu TokyoEkiMae 03-3275-3691
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp