From: bm...@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.