From owner-freebsd-questions Mon May 20 22:46:46 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id WAA29017 for questions-outgoing; Mon, 20 May 1996 22:46:46 -0700 (PDT) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id WAA29006 for ; Mon, 20 May 1996 22:46:43 -0700 (PDT) Received: from Early-Bird-1.Think.COM by mail.think.com; Tue, 21 May 96 01:46:40 -0400 Received: from compound.Think.COM by Early-Bird.Think.COM; Tue, 21 May 96 01:46:37 EDT Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id AAA20060; Tue, 21 May 1996 00:47:39 -0500 (CDT) Date: Tue, 21 May 1996 00:47:39 -0500 (CDT) Message-Id: <199605210547.AAA20060@compound.Think.COM> From: Tony Kimball To: bmah@cs.berkeley.edu Cc: terry@lambert.org, questions@freebsd.org In-Reply-To: <199605210513.WAA24403@conviction.CS.Berkeley.EDU> (bmah@cs.berkeley.edu) Subject: Re: ip masquerading Sender: owner-questions@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From: bmah@cs.berkeley.edu (Bruce A. Mah) Date: Mon, 20 May 1996 22:13:03 -0700 Tony Kimball writes: > Hey, I'm not the one who wants to recover state. I'm just trying > to scam out how it could be done. You've got a good 15.97 bits to > work with... It's also kind of hard to cram 32 bits of IP address and X bits of port/application/whatever (where X is small) into 16 bits of port number, without needing some other kind of shared state. But of course you don't need 32 bits of IP. If you allocated 7 bits to a client IP table index, 5 to client port and 3 to stream protocol, that would probably cover the needs of 99.9% of the "customers". If there were any. Frankly I think the issue is a red herring tossed out by the con masquerade team. Doing automatic state recovery would be throwing good money after bad. The socks*socks plumbing scheme of terry, which seems the best candidate to date, wouldn't do this anyhow without substantial modification. > "real" proxies are still rewriting packets. They're just > spending a lot more to do it. That's okay, though. "Real" proxies transform data in the application layer, not by rewriting packets at the network layer. Like I said, just spending a lot more to do it. It's just a black box. Packets go in, packets go out. They've been rewritten. > The point is to make it work, not to make it work efficiently. To quote Terry: You have *got* to be kidding! If you wanted efficiency, you'd run linux masquerade. There's no way an application layer proxy is going to shake a stick at masquerade integrated in the stack. Without looking, I bet the linux masquerade is zero-copy. Fortunately we're not talking about OC-12 speeds here, as a rule. Some very large proportion of the users will never see the difference, so they won't care, and FBSD will provide adquate masquerade for their purposes.