From: Terry Lambert <ter...@lambert.org> Date: Mon, 20 May 1996 15:45:51 -0700 (MST)

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").

Couldn't state be inferred from the retry packets?

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.

It would be nice to pull out the rewriting stuff into loadable rule sets.

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.

I'm trying to picture this, but I'm crippled by lack of understanding of the tunnel device. There is a box, G. It has a network interface, I(G), on the Internet. It has a network interface, P(G), on a private net. Hosts on network P route through P(G) to get out through I(G). G is implementing masquerade, then. I don't understand what you are saying about the structure of the implementation.

> 4. It's not a general purpose solution (e.g. ICMP doesn't work...

The is the second of the *big* problems.

I don't understand why it is a big problem. It is a big problem if you are trying to put the private machines on the Internet, but I don't see that as being the goal. The goal is to get TCP applications (and secondarily UDP applications) to run transparently from a private network home through an Internet gateway. If the gateway violates host requirements, *that* is a problem.