TCP/IP Tutorial and Technical Overview - IBM Redbooks

24.8.2 Encapsulation
As shown in Figure 24-6 on page 922, NAT offerings sometimes enforce the
need to see both inbound and outbound requests by obliging the NAT device to
be installed as a bridge (without permitting bridges of any other kind), thus
forcing the servers on to what is essentially a private segment. This can
complicate installation, because it requires a significant physical change to
existing networks. All traffic for those servers must pass through the load
balancer whether the traffic is to be load balanced or not.
The one advantage of NAT as originally conceived (the ability to forward packets
to remote destinations across a wide area network) cannot be usefully deployed
because the wide area network connection is behind the bridge and, therefore,
can only be within the site's private network. Additionally, the same NAT device
must still be the only exit from the wide area network link.
To attempt to overcome these limitations, some NAT solutions add to the overall
inefficiency that is fundamental to NAT by providing add-ons. For example, the
capability to map one port address to another. Refer to “Network Address Port
Translation (NAPT)” on page 93.
To check if a server is up, NAT-based load balancing solutions need to sacrifice
an actual client request, and so a server outage is typically perceived only as a
result of a timeout of one of these real client requests.
NAT devices often only map affinity or stickiness based on the client's IP
address, and not at the port level. This means that after a client has contacted a
server, all traffic from that client that is intended for other applications is
forwarded to the same server. This drastically restricts configuration flexibility, in
many cases rendering the sticky capability unusable in the real world.
Another approach to load balancing is proxies that encapsulate packets rather
than modifying them, and then pass them to the server. This approach has some
merit, particularly because it permits the load balancer to forward traffic across a
wide area network, unlike the bridging NAT solutions. But other implementations
use encapsulation for all traffic, and this requires an agent of the load balancer to
be installed on each server. This agent reverses the encapsulation process. As a
result, the choice of server platform is, by definition, restricted to the platforms for
which the server agent is available. Also, like NAT, it entails further processing of
the packet, which increases the likelihood that it will not be scalable to the levels
required for major sites.
Encapsulation is discussed in further detail in RFC 1701, which appears to be
updated by RFC 2784.
Chapter 24. Availability, scalability, and load balancing 923