SOCKS [RFC1928] is another example of a transport relay but it is usually referred to as a “proxy protocol for client/server environments”.

A SOCKS proxy works in a similar fashion as a traditional transport relay, but there are minor differences, which we will now describe.

When a client wants to connect to an application server it first sets up a connection to a well known, preconfigured proxy server using a special proxy protocol. The client informs the proxy about the IP address and the port number of the application server it wants to communicate with. The proxy server is now responsible to set up a connection to the application server. As soon as this connection is up and running the proxy relays packet between the client and application server hiding the actual connection.

component is located in the application layer while the client component is located between the client application and the transport layer.

Before an application client can use SOCKS it has to be modified (“socksified”). This can be done in two different ways: If the source code is available it can be compiled together with the SOCKS client library using a set of pre-processor directives. If one has instead only precompiled binaries for an application, but the operating system supports dynamic linking of shared libraries one can change some environment variables in the operating system so that the client uses SOCKS instead of the default network libraries.

RFC 3089 [RFC3089] presents a SOCKS-based IPv6/IPv4 gateway mechanism that supports both IPv6 to IPv4 communication and IPv4 to IPv6 communication. This RFC also contains a link to two different implementations of the mechanism described.

No 6NET partners are currently using SOCKS for IPv6 transition purposes.