Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 May 1996 21:46:48 -0500 (CDT)
From:      Tony Kimball <alk@Think.COM>
To:        terry@lambert.org
Cc:        questions@freebsd.org, archie@whistle.com
Subject:   Re: ip masquerading
Message-ID:  <199605180246.VAA00761@compound.Think.COM>

next in thread | raw e-mail | index | archive | help

  From: Terry Lambert <terry@lambert.org>
  Date: Fri, 17 May 1996 18:13:39 -0700 (MST)
  Subject: Re: ip masquerading

  > You give all of the outgoing
  > packets the same IP address but remap their source ports so when
  > traffic comes back you know who it is really destined for, do the
  > reverse mapping, etc..

  Which is to say, you turn on IP forwarding by default (which is illegal)
  and rewrite the packet source headers on the way in and out (which is
  also illegal).

If anyone knows how these actions are in violation of a requirement,
I'd surely appreciate a pointer to the pertinent rfc.  They are part
of the implementation of the IP stack on the host, which in this case
is the *system* incorporating the masquerading server and client.
Internet requirements documents do not specify implementation, merely
interface.

  > Now, as far as the rest of the Internet is concerned, it just looks
  > like your one IP address happens to be generating a lot of traffic, no?

  Prove it.  Run traceroute through a masquerading host.

Clearly the implemenation would terminate the route at
the masquerading host, yes?  You would not trace through, but to,
the Internet interface of the multi-host system.

  > At least under the (not always valid) assumption that you don't run
  > out of ports in your remapping range. What standards in particular are
  > you referring to?

  1)	Gateway
  2)	Routing

  Garrett explained this all before.

I haven't been able to find anything in the archives.  If you have
it cached anywhere or can suggest a more apposite keyword, I would
appreciate it.

Frankly, I just don't believe it.  You may write an implementation
of masquerading which is deficient, and causes your host to violate
requirements, in which case you are a turd and I sniff at you,
or you may write an implementation which is not deficient, in which
case the masquerade client is (for rfc purposes) a *part*of* your
masquerade server, and the *system* fulfills host requirements
-- and that is all that is necessary, for it is the *system* 
(incorporating an internetwork as a component) which is connected
to the Internet.

  Writing a socks client that hooks to a tunnel driver on the machine
  that needs the masquerading is a better solution, and it doesn't
  require kernel hacks to get there (or source hacks for statically
  linked binaries, like normal socks does).  And it does it without
  violating the world.

Ah, but it requires running FreeBSD on my toaster, my Amiga, my
lawnmower, in short everything I have that does IP traffic.
Sorry, but my toaster is not going to fulfill host requirements.
In order to conform to rfcs, I need something to provide masquerade
for my toaster, otherwise I will never be able to turn of the stupid
thing when I'm in Bangkok, and the flaming pop-tarts will burn down
my house.  




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605180246.VAA00761>