An Application Layer Gateway (ALG) is a common mechanism to allow users behind firewalls or behind a NAT gateway to use applications that would otherwise not be allowed to traverse the firewall or NAT gateway. A common example for an ALG is a classical HTTP proxy like “squid” or “wwwoffle”.

The principle of an ALG can easily be explained using an HTTP proxy as an example. Normally, a web browser would directly open a connection to a web server if a direct connection between the client and the server can be established. However, when using an ALG, the client opens a connection to the ALG (in this case the HTTP proxy), which (if the required content is not already cached locally from a previous request) then itself establishes a connection to the webserver acting as a relay for outgoing requests and incoming data. In most cases, the use of an ALG is almost transparent for the user. Applications that use ALGs have to be configured to do so beforehand. A web browser has to be configured to use a certain HTTP proxy, for example. There are also applications that allow automatic configuration of ALGs.

In IPv6-only networks, the ALG functionality can be used to enable hosts to establish connections to services in the IPv4-only world and in some cases the other way around as well. This can be achieved by setting up ALGs on dual-stack hosts, which have both IPv6 and IPv4 connectivity. The only difference between a normal application proxy and an ALG in this case is that it will use IPv6 transport in the internal network to receive requests but IPv4 to relay the requests to outside IPv4-only communication partners.

ALGs are the “translation” method of choice for most 6NET sites, simply because many common applications naturally support this mode of operation (web proxies, SMTP MXs, IRC servers, etc).