From owner-freebsd-questions Mon May 20 15:50:10 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA25729 for questions-outgoing; Mon, 20 May 1996 15:50:10 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id PAA25723 for ; Mon, 20 May 1996 15:50:07 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA28777; Mon, 20 May 1996 15:45:51 -0700 From: Terry Lambert Message-Id: <199605202245.PAA28777@phaeton.artisoft.com> Subject: Re: ip masquerading To: bmah@cs.berkeley.edu Date: Mon, 20 May 1996 15:45:51 -0700 (MST) Cc: alk@think.com, questions@FreeBSD.ORG In-Reply-To: <199605201537.IAA09391@premise.CS.Berkeley.EDU> from "Bruce A. Mah" at May 20, 96 08:37:53 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > OK. Here are my technical gripes with IP masquerading: [ ... ] > 1. It introduces hard state in the gateway machine. If the gateway > goes down and comes back up, you lose all the connections through it. > Note that some other approaches such as application-specific gateways > have this problem too. This is one of the *big* problems I see. The recovery mechanism to get around this requires an intelligent client (ie: not Windows 95) and the ability to recover state (ie: the client knows the state, too (ie: not Linux-style "masqueraing"). > 2. The Linux implementation (which I've examined *briefly*) puts all > kinds of application-specific stuff *in kernel*. There are all kinds > of clever tricks to get FTP, RealAudio, and other applications to work > right. Layering? What layering? The packet rewriting is a bit annoying; on the other hand, there are a finite number of protocols that really need to be supported this way, so it's bad, but it's not as bad as it could be. I am utterly amazed that Linux puts IP proxy services in the kernel, yet the same time puts the NFS server in user space. 8-|. > 3. There already exist other methods for doing what IP masquerading > does (for example SOCKs, application-specific gateways). Why does > FreeBSD need another? Socks really wants two additional tunnel-to-socks and socks-to-tunnel daemons written; using two private nets, this would let you run a private net of socks-unaware hosts that get their packets proxied by setting up a default route, a private net route to one tunnel on one private net, and a default route to the other tunnel on the private net with the dumb hosts. Effectively, a gateway LLB in user space. > 4. It's not a general purpose solution (e.g. ICMP doesn't work, UDP > support is a hack). For example, how would I ping outside my local > network to track down problems? The is the second of the *big* problems. > Just so people don't think I'm completely one-sided about this: > > 1. IP masquerading does slow down the rate that addresses get used up, > and, more importantly, the routing table size at the neighboring > network. This is a weenie answer (I realize you're just quoting here ;-)) and assumes IPv4 for eternity. It's bad because it codifies the current system. What we're really talking about here is differences in charges for routing table entries -- an artificial stair-step invented by some ISP's to make money (their routing hardware generally doesn't care). > 2. Extremely reluctantly, "Linux does it". If Linus jumped off a bridge... 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.