Home ¤ Technical Papers ¤ Downloads ¤ Companies ¤ News ¤ Contributed Articles ¤ Books

Network Address Translation in Embedded Systems

By Hank Heneghan
Director, Product Management
Performance Technologies
www.pt.com

Background
The development of embedded industry standards such as PICMG®2.16, AdvancedTCA and the proposed CompactTCA all indicate a movement away from master/slave, bus-based architectures to networked, peer architectures. While this new approach to embedded system design offers several advantages in system architecture such as scalability, fault tolerance, cost and time-to-market, you must have an Ethernet network that can support a number of advanced features. This is where we begin our discussion on Network Address Translation (NAT) and its use in an embedded environment.

Though once thought to be impossible, the world is running out of IP addresses. Several countries have almost entirely exhausted their allocation of IP addresses and have become dependant on NAT as a means to combat this problem. NAT connects a myriad of devices together by converting a set of private IP addresses to another set of public Internet IP addresses, under rules issued by the Internet Assigned Numbers Authority (IANA). Today, NAT is used primarily to share external network connections among a number of internal users. It is also used to shield internal networks from an outside observer or to dynamically share processing load across a pool of servers.

A NAT server typically sits on the border between private and public networks, where it provides transparent packet forwarding between addressing realms. The NAT router is assigned a public address (or series of addresses) that can be used by external devices to communicate with internal devices, as shown below:

When a client attempts to communicate with a server on the opposite side of a NAT boundary, a NAT session is triggered. The NAT engine intercedes in this process by setting up two independent TCP/UDP streams - one between the session initiator and the NAT engine, the other between the NAT engine and the public server. NAT transparently disassembles and re-assembles the packet so that both the public and private side are unaware NAT is taking place and then routes datagrams over the boundary. This mapping is maintained until the session ends so that in-bound packets can be returned to the correct node.

NAT makes it very easy to make changes to your internal network, since there is typically only a single external IP address belonging to the NAT module itself, thus shielding internal changes from the outside environment. This enables integrators of embedded systems to pre-configure the internal/private IP addresses of the blades (or nodes) in the chassis. When the system is delivered to the field, only the external/public IP addresses for the installation site have to be set.

NAPT
Network Address Port Translation, or NAPT, makes it possible for several hosts to share a single IP address by multiplexing streams differentiated by a combination of internal IP addresses and TCP/UDP external source port numbers. The NAT module assigns a unique mapping to this combination of internal/external IP addresses and software port numbers and maintains this "association" in a lookup table for the duration of the session between the internal node and external device.

NAPT is commonly implemented on the NAT server to enable masquerading/sharing, giving multiple inside users simultaneous access to outside resources for an entire internal LAN through a single public address. Additionally, NAPT increases network privacy by hiding IP addresses from external networks. Because NAPT works with unique combinations of IP addresses and individual software port numbers, it is not possible for outsiders to "reverse map" incoming connections to get to other nodes within the chassis.

NAPT Diagram

Having NAPT services provided by the NAT module and DHCP running on the switch carrier card is a natural fit. You can choose a range of unregistered IP addresses for your internal network and have the embedded switch dole them out as necessary. This also makes it much easier to maintain or scale up your network as your needs grow, since you don't have to request more public IP addresses. Network managers can just increase the range of available internal IP addresses configured in DHCP and immediately have room for additional nodes in their system.

STATIC NAT
With Static NAT, a fixed mapping between external and internal IP addresses is established on a one-to-one basis. You would typically use Static NAT to provide security for the internal network, hiding the inside from the outside while allowing sessions to be initiated on either side. As an example, multiple external clients may connect to an external global address. This external address is then mapped to a specific inside local address. In this manner, the outside address can be assigned to a particular server blade within your system.

Static NAT is often used where a block of public IP addresses is provided by an Internet Service Provider (ISP) for use by the same number of internal client nodes. This static mapping allows the internal clients to maintain their setup information, even if the public IP addresses change. Multiple ISP's can be enlisted to provide a degree of fault-tolerant access to a system. If network performance or quality degrades, connections can be swapped to another supplier, with only the NAT module's external addresses needing to be changed. The NAT's single management interface makes changeover a much easier task.

Static NAT Diagram

DYNAMIC NAT
NAT also supports Dynamic NAT, where the bindings between internal and external client/servers are not pre-set but follow established rules specifying the mapping of a group of internal IP addresses to a pool of external IP addresses. The number of public addresses is usually smaller than the number of internal addresses. Dynamic NAT is used in cases where you want to allow the internal nodes shared access to public IP addresses. Only one of the internal nodes can be mapped to an external address at a time. These mappings can be set to expire if they are not used within a programmable period of time.

By implementing Dynamic NAT and the appropriate filters, a firewall is created between your internal network and outside networks or the Internet. Dynamic NAT only allows connections that originate inside the internal domain, so a computer on an external network cannot connect to one of the internal servers unless the internal node has initiated the contact. Outside users can't simply latch onto an internal IP address and use it to connect to a software port or an internal node. Once again, this allows integrators to set the internal addresses in the factory and only have to manage the NAT module interface when the system is installed at a customer site.

Dynamic NAT Diagram

STATIC NAPT
Mappings for Static NAPT specify translations between a single private IP address and private TCP/UDP service port pair and a single public IP address and public TCP/UDP destination service port pair. Unlike NAPT and Dynamic NAT, sessions may originate on either the public-side or the private-side. Static NAPT differs from Static NAT in that both the IP address and the TCP/UDP service port are translated in both directions. Static NAPT also allows the network administrator to select the port numbers used. This allows sessions from a particular client to be directed to a particular server.

Static NAPT is typically used at both ends of a client/server connection to create a "tunneled" connection over a public network. At one end of the connection, the clients are hidden behind a Static NAPT-enabled module. That module translates well-known TCP/UDP (destination) port numbers to administratively-specified port numbers that are unique to that client. At the other end of the connection, the servers are hidden behind another Static NAPT-enabled module that translates the destination port number back to a previously-determined destination IP address in the private-side domain.

Shown below is an application that allows public-side access to private-side servers and provides the network designer with control over which public-side client is mapped to each private-side server.

Static NAPT Diagram

Load Sharing NAT
Load Sharing NAT (LSNAT) enables the NAT module to distribute a session load across a pool of servers. LSNAT is most often used in embedded server farms, where a single blade server is not able to cope with the demands of an increasing number of clients or sessions. Load sharing is used to decrease response time for each function by leveling the work each server has to do. It also allows systems to grow over time by transparently adding servers to handle increasing session load. LSNAT combines the transparent address translation of NAT with real-time load share algorithms. LSNAT can also be used within a private routing realm, on two different subnets, to provide load-sharing functionality.

When a client attempts to access a server through a user defined virtual server IP address, NAT selects a node from within a server pool based on one of two criteria: by establishing a connection with the next available server node (round-robin), or by assigning the session to the server with the lowest number of open sessions within that group of severs (least load first). NAT can be configured to periodically check the health of all attached servers in a pool. Non-responsive nodes can be automatically removed from the group, and once the server begins to operate again or is replaced, NAT will assign new sessions to it.

LSNAT makes it very easy to reorganize and rearrange server nodes in the chassis. Nodes in a server pool may be replaced or upgraded, or new nodes may be added without the clients being aware of any background activity. Changes to servers, whether blade- or box-based, can be shielded from client nodes by making the NAT module the focal point for change management and network traffic. All requests and responses pertaining to a session between a client and server node pass through the same NAT, giving designers a single control point for all traffic to and from an "internal" domain.

Load Sharing NAT Diagram

Conclusion
Today, PICMG 2.16 and the proposed CompactTCA spec are the only open standard means of providing server blade systems. While closed systems from single vendors are available, designers lack the flexibility to choose the exact processor and I/O blades, operating systems and applications that would make the best choice for their product.

As designers move away from bus-based systems, they are going to need increasingly sophisticated networking technologies in order to produce more complex and powerful (yet easier to manage and maintain) systems. Given its transparent packet processing and flexible management capabilities, NAT makes a perfect addition to an embedded network system design.