Page 5 of 11

EFFECTS OF ADDRESS SPACE CHOICES ON DATA CENTER IMPLEMENTATION

The scarcity of IP addresses drives many implementation and technology choices. In this section, we discuss some of these choices, particularly Network Address Translation, the complications of implementing Network Address Translation, and web server implementations.

Network Address Translation
A very useful service that an Internet data center can offer is connectivity between a customer’s internal network and their servers hosted at the data center. One problem that such a service can encounter is conflict between private address spaces. The resolution of private IP address conflicts can affect address space design choices made at the customer end as well as those made for data center internal networks. Another major design factor is the preference to hide customers’ internal networks from being seen in the data center network.

A popular technology used for resolving IP address conflicts is Network Address Translation (NAT) [14]. NAT helps translate IP addresses to a non-conflicting IP space and can be used to resolve IP conflicts that occur between a customer network and data center internal networks, as well as those that occur between two different customers’ networks. There are two different modes of NAT:

• many-to-one or many-to-few NAT
• static one-to-one NAT

Figure 2: Many-to-one NAT packet flow

Figure 2 shows a sample flow of how a packet changes as it traverses the many-to-one NAT boundary between networks A and B. Any traffic traversing from network A (designated by 192.168.43.0/24) to network B has its source IP address translated to a single IP address (209.23.151.16). To differentiate the multiple hosts on network A trying to communicate with hosts on network B, the source port 4321 is also translated to a dynamically assigned port 1234 as the NAT boundary is crossed. The device performing NAT maintains a dynamic table of these IP addresses and port translations to ensure appropriate communication between network A and network B.

A consequence of using many-to-one or many-to-few NAT is that network communication cannot be initiated bidirectionally. Consider the example in Figure 2. Network communication can be initiated from hosts on network A to those on network B. Hosts on network B cannot initiate connections to hosts on network A because network A is hidden behind a single IP address 209.23.151.16, and hosts on network B cannot uniquely address a host on network A for communication. This could potentially be considered a security feature as well.

Static one-to-one NAT entails translating an IP address uniquely to another IP address. In addition, static NAT does not involve any port translation. Further, there is no restriction regarding which direction network communication can be initiated in because the device performing NAT can uniquely translate back to a specific host on the network with the conflicting IP space.

Based on network communication requirements, many-to-one or static NAT or both can be used. Later on, we discuss how Intel Online Services uses NAT for IP conflict resolution under various remote access scenarios. Extensive use of NAT also drives the need for choosing a device that allows enabling of flexible NAT configurations to fit the diverse requirements of multiple data center customers.

NAT may need to be used more than once as the network traffic traverses between the customer networks and the data center networks and back. An example of such a situation is when one customer’s internal IP space conflicts with another customer’s internal IP space. In such a situation, NAT would need to be performed at one of the customer ends to resolve IP conflicts with the other customer’s IP space. NAT would need to be used a second time at the data center end to hide the customer network from data center internal networks.

To further complicate matters, there could be situations where a customer needs to run applications such as DCOM [16] that do not work across NAT. In such situations, alternate solutions like readdressing customer end systems to a public IP space and allowing that IP space to be visible within the data center may need to be explored.

Debugging Complications from NAT
While NAT can be a very useful tool for resolving IP address conflicts and enabling end-to-end connectivity to customer-end networks, the use of NAT can lead to complex troubleshooting scenarios [17]. In situations where NAT is performed more than once as a packet transits from its source to its destination, the IP address of an end system will change as many times as a NAT boundary is traversed. Debugging access issues in such cases requires intimate knowledge of the end-to-end network path and also a clear comprehension of which IP address is associated with an end system on a given section of that network path.

A packet sniffer is critical when troubleshooting potential connectivity issues across a device performing NAT. Visibility inside the packets captured on both sides of the NAT boundary helps establish whether the IP address translation is occurring as desired. Looking at the payload in a packet can also help identify if an application will work across a NAT boundary. Usually, applications that contain IP addresses or application port information in the packet payload will not work across NAT as the NAT process modifies the IP address only in the IP header and does not modify anything in the packet payload. Without visibility into a packet, this kind of troubleshooting could be long and tedious.

Use of NAT can also lead to configuration complications on the end systems since the translated address is valid on one side of a NAT boundary and the actual IP address may be valid on the other side of that NAT boundary. For example, when printing to a printer whose IP address has been statically translated (one-to-one), let’s say from the actual printer IP of 172.16.20.5 to an IP address of 10.81.249.23, the print job will need to be initially sent to the translated IP address i.e., 10.81.249.23. Consider another case where the printer IP address is translated from its actual IP address of 172.16.23.15 to 192.168.23.26 at the customer end and is further translated to 10.81.249.35 at the data center. In this case, the system at the data center will need to send a print job to 10.81.249.35 in order to print to the actual printer at 172.16.23.15.

Furthermore, in the case of many-to-one or many-to-few NAT, the network traffic can only be initiated in one direction as discussed earlier. This should be kept in mind when troubleshooting connectivity issues across such address translation boundaries.

Virtual Web Server Implementation
Data center customers occasionally implement what are called virtual servers. This means that multiple web sites are implemented on the same set of servers. One way to implement this is to use a different IP address for each web site, with each web server having multiple IP addresses. Each IP address corresponds to a different web site. For example, let us say a customer has three web servers (1, 2, and 3) and two different virtual servers, www.site1.com and www.site2.com. Each web server would have two virtual IP addresses, one for www.site1.com and another for www.site2.com. www.site1.com would map to an IP address which is load balanced between the three site 1 IP addresses. www.site2.com would map to a different IP address which is load-balanced between the three site 2 IP addresses. This configuration consumes eight public IP addresses.

Extending this logic for m web sites and n web servers, m * (n+1) public IP addresses are consumed. This is a very wasteful way to use IP addresses. A better implementation uses virtual sites for customers with only one IP address per server. The web server produces content depending on the HTTP host request header [17]. As a result, for m web sites on n servers, only n+1 IP addresses are consumed (including one virtual address per site). The shortage of IP address space dictates using this technique. Some registries will not accept virtual sites as an excuse for requesting additional IP addresses.