Date: Tue, 21 May 1996 00:47:39 -0500 (CDT) From: Tony Kimball <alk@Think.COM> To: bmah@cs.berkeley.edu Cc: terry@lambert.org, questions@freebsd.org Subject: Re: ip masquerading Message-ID: <199605210547.AAA20060@compound.Think.COM> In-Reply-To: <199605210513.WAA24403@conviction.CS.Berkeley.EDU> (bmah@cs.berkeley.edu)
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605210547.AAA20060>