Overview of Network Address Translation (NAT) in Windows XP

On This Page

	Introduction
	What is NAT?
	General NAT Operation
	Common Issues with NAT and Applications
	Impact on Customers and Industry
	What is NAT Traversal?
	NAT Traversal Operation
	NAT Traversal APIs in Windows XP
	Supporting NAT Traversal in Internet Gateways
	How Applications Make Use of NAT Traversal
	Limitations of NAT Traversal
	Conclusion

Introduction

As more homes and small businesses add computers they are finding networking is an extremely powerful tool for sharing computer resources. An Internet connection is one of the more precious resources on the network and is likely to be shared. To do this and to enjoy an inexpensive, easy to manage, home or small office network, Internet gateways are being deployed. Internet gateways often provide NAT (Network Address Translation) as a means of connecting multiple hosts to the Internet sharing a single public IP address. Unfortunately, this solution breaks many types of networked applications—as will be described in this paper.

NAT Traversal technology has been created to enable network applications to detect the presence of a local NAT device. Once detected, the application can then configure the NAT, defining the appropriate mappings to solve their compatibility issues.

This paper is an overview to introduce consumers and developers of network applications to NAT, identify common NAT problems, and review how NAT Traversal can be used by applications to address these problems. Technical details of the NAT Traversal APIs provided in Windows are scheduled to be available in the Windows Platform SDK beginning in the early summer 2001; developers are encouraged to review these resources for more detailed explanations of how to capitalize on these new operating system capabilities that also extend to third-party gateway devices.

NAT Traversal relies on the NAT device providing UPnP technology support. An important feature to look for in an Internet Gateway device is UPnP certification. Consumers purchasing or leasing from their service provider an Internet gateway device are strongly encouraged to consider only those devices that are UPnP certified for NAT traversal because this feature makes such an important difference with respect to customer satisfaction, lower support costs, and the use of more innovative services and applications.

Adding UPnP technology support for NAT traversal to an Internet gateway device is not a complex, expensive or time-consuming endeavor for the gateway device vendor. By using UPnP technology, which is already based on Internet standards and protocols, the Internet gateway device vendor can solve this problem of NAT traversal and have those benefits extend to most any application that traverses their device. This is in sharp contrast to the one-off solutions that many application developers or gateway device vendors have to provide today to solve these problems. This paper is not a detailed guide for hardware vendors desiring to implement NAT Traversal in Internet gateway devices. For this information, please see the UPnP Forum Web site.

Knowledge of Windows architecture, networking and the UPnP architecture will be helpful, but not required, to fully understand this paper.

What is NAT?

Network Address Translation (NAT) is an Internet Engineering Task Force (IETF) standard used to allow multiple PCs on a private network (using private address ranges such as 10.0.x.x, 192.168.x.x, 172.x.x.x) to share a single, globally routable IPv4 address. A main reason NAT is often deployed is because IPv4 addresses are getting scarce. Internet Connection Sharing in Windows XP and Windows Me, along with many Internet gateway devices use NAT, particularly to connect to broadband networks such via DSL or cable modems.

NAT is an immediate but temporary solution to the IPv4 address exhaustion problem that will eventually be rendered unnecessary with IPv6 deployment. This IPv4 address exhaustion is a particular problem in Asia and other geographies around the world and will increasingly become an issue in North America. Hence, the interest in using IPv6 to overcome this issue longer term.

In addition to reducing the number of IPv4 addresses needed, NAT also provides a layer of obscurity for the private network, because all hosts outside of the private network observe communication through the one shared IP address. NAT is not the same thing as a firewall or a proxy server, but it does contribute to security.

General NAT Operation

Clients behind a NAT device are assigned private IP addresses, usually through DHCP (Dynamic Host Configuration Protocol) or static configuration by an administrator. When communication outside of this private network takes place, the following things normally occur.

On the Client

When an application wants to talk to a server it will open a socket associated with a source IP address, source port, destination IP address, destination port and network protocol. This identifies both endpoints for the communication to take place. When the application transmits information using the socket, the client's private IP address (source IP address) and port (source port) are inserted into the source fields of the packet. The destination fields of the packet will contain the servers IP address (remote host – destination IP address) and port. Because this packet is destined for a location off of this private network, the client will forward this packet to the default gateway. The default gateway in this scenario is the NAT device.

Outgoing Packet at the NAT Device

The NAT device will intercept this outgoing packet and create a port mapping using the destination IP address (server), destination port, external IP address of the NAT device, external port, network protocol, and the internal IP address and port from the client.

The NAT device will maintain a table of these mappings, storing this port mapping in the table. The external IP address and port are the public IP address and port to be used by for this data traffic in place of the internal client's IP address and port.

The NAT device then "translates" the packet by swapping the source fields of the packet from the private, internal IP address and port of the client to the public, external IP address and port of the NAT device.

The packet is then sent on the external network to eventually reach the intended server.

At the Server

When the server receives the packet, it thinks it is talking to a single machine with a globally routable IP address. It will address response packets to the external IP address and port of the NAT device, using its own IP address and port in the source fields.

Incoming Packet at the NAT Device

The NAT receives these packets from the server and compares the packets to its table of port mappings. If the NAT finds a port mapping where source IP address, source port, destination Port, and network protocol of the incoming packet match the remote host IP address, remote port, external port, and network protocol of the port mapping, the NAT will perform a reverse translation. The NAT replaces the external IP address and external port in the destination fields of the packet with the clients private IP address and internal port.

Then NAT then sends the packet on the internal network to the client. However, if the NAT doesn't find a corresponding port mapping, the incoming packet is dropped and the connection will break.

The effect of NAT is the client will be able to communicate on the global Internet with a private IP address, without any extra effort on the part of the application or client. This means the application will not have to call additional APIs and the client will not have to perform additional configuration. In this case, the NAT is transparent to both the client and the server application - everything just works.

However, not all network applications use protocols that work with NAT. Therein lies the problem.

Common Issues with NAT and Applications

Having clients use NAT to share a single globally routable IP address works okay when the client, initiates the contact and receives a reply on the same port. Many applications, however, use strategies that make assumptions that become false assumptions when a NAT device is used to connect to the Internet. Some of these issues are discussed here.

Services on the Internal Network

Many network services or servers assume that if they establish a listening socket, any client on the Internet can initiate contact with them. If there is a NAT device on the edge of the network, NAT requires that a port-mapping exist in order to forward incoming traffic to services on an internal network. Because of this, the service only works for clients on the private network - it is unavailable to the rest of Internet.

The most common work around for this issue is to manually configure a port mapping that will cause the NAT device to forward traffic addressed to a specific external IP address and port of the NAT to the internal IP address and port used by the service.

With this port mapping in place, services can receive incoming packets – making the service accessible to clients external to the private network. Until the port mapping is made, the network experience is broken.

Manually configuring this mapping is usually complicated and requires a more experienced user in order to configure the mapping correctly. As a result, many consumers or small business users are not able to use the applications or services they desire unless they contact customer support of their broadband Internet service provider, PC manufacturer, retailer, or Internet gateway vendor trying to sort out the source of and solution to the problem. This also results in a less restrictive mapping – any external client can use this mapping to initiate contact with the server.

Embedded Addresses or Ports

Some network applications assume the IP address and port the client has been assigned will always be globally routable and can be used on the Internet directly. In many cases they are private IP addresses from IETF reserved address ranges. The application will include this private IP address or port in the payload of packets sent to the server. The server may use this embedded address as the address to contact the client.

If the server attempts to reply using the embedded IP address and port instead of the mapped address and port supplied by the NAT, the packet is dropped. This occurs because the embedded IP address is non-routable. If the network application could discover the presence of a NAT device, and retrieve the external IP address and external port mapping to be used, the application could embed the right information in the packet.

Applications Using Disparate Sockets

Other network applications send traffic to a server or peer using a socket on one port "X" and expect to receive traffic from the server to a separate listening socket on port "Y". The NAT sees the outgoing traffic and creates a port mapping for port "X", but does know to make a port mapping for the return packets addressed to port "Y". Incoming packets addressed to port "Y" are dropped.

Expecting Ports to be Available

Some network protocols assume that a globally routable, well-known port will always be available to them. When multiple clients share an IP address, only one client can use the well-known port at one time. For example only one web service can use the external port 80 on a local network at a time. If this were not the case, the NAT device would be unable to determine which client the external request applied to. Even with the aid of a user configuring port mappings special measures must be taken if multiple clients are to be discovered from outside the local network.

Multiple NATs

If a client is behind a NAT which is behind another NAT, new problems beyond the scope of this paper appear.

Impact on Customers and Industry

The previous paragraphs describe the technical phenomena associated with NAT traversal. The impact of this from a user perspective is simple: people cannot use the services or applications they want to use when NAT interferes.

Most users today do not even realize they've been a "victim" of this NAT issue. All they know is that when they try to enjoy multi-player gaming or engage in peer-to-peer applications, such as real time communications, or use some other application, they cannot. They may see some sort of "cannot connect" error message on their PC or perhaps their application will attempt to work and then just fail.

In some cases, a user with a dial-up modem connection to the Internet will have no issues with these experiences while using the dial up modem. Then, when the user signs up for broadband service and begins using a DSL or cable modem device with NAT, the problems occur. Expecting to enjoy a faster Internet experience, these users, in particular, can be baffled by the NAT issue that suddenly inhibits their ability to play games or enjoy other services.

This causes customer dissatisfaction, which can be directed at the PC vendor, the ISP, the Internet gateway vendor, or others. Often, the customer does not know what the source of the problem is and technical support staffs do not always know how to troubleshoot these problems over the phone.

This is not just an issue for the user. It also is an issue for the vendors that provide products and services to the user. The support calls the customer makes to try to resolve these NAT-induced problems cost money and can reduce or eliminate a vendor's or retailer's profitability. These issues can cause some users to be less interested in new services or applications due to lack of satisfaction with previous services the user has attempted, so NAT can be an inhibitor to more innovative product/service offerings and adoption.

Given these factors, solving this NAT issue is an important task for the industry.

What is NAT Traversal?

NAT Traversal is a set of capabilities that allows network-aware applications to discover they are behind a NAT device, learn the external IP address, and configure port mappings to forward packets from the external port of the NAT to the internal port used by the application – all in an automated fashion so the user does not have to manually configure port mappings or other such mechanisms.

This is a more holistic solution to the connectivity issues caused by NAT than other application-specific methods that have been employed to-date. Such specialized solutions to-date required either technical knowledge on the part of the user, special development arrangements of development efforts on the part of application developers or Internet gateway vendors, or all the above.

Though NAT traversal addresses some of the problems with NAT, it is not a panacea, and does NOT solve everything. Still, NAT traversal in this automatic fashion represents a significant step forward with regard to improving customer satisfaction, reducing customer support calls and enabling new, innovative services and applications, particularly in a home network situation.

NAT traversal should be thought of as a coping mechanism that should be used when needed, but will not work in all situations. NAT and therefore NAT traversal will no longer be needed in an IPv6 world where every client has a globally routable IP address. Forecasts vary with regard to how quickly IPv6 will enjoy pervasive deployment. The industry, including Microsoft, is making significant investments to move forward with IPv6, but the NAT traversal solution described in the remainder of this document can make a real difference now and for the next few years for consumers and small business users who want to overcome NAT issues.

NAT Traversal Operation

NAT Traversal relies on discovery and control protocols that are part of the UPnP architecture specifications. The UPnP Forum has a working committee focused on defining the control protocol for Internet gateway devices and defining the services for these devices.

Internet gateway devices that support the required elements of the Internet Gateway Device control protocol will advertise their presence and publish XML description documents to control points on their local network. From these XML description documents, it is possible for control points to learn what actions to call to determine if an Internet Gateway has a NAT enabled, get the external IP address of the NAT, and create port mappings.

The NAT Traversal API in Windows abstracts the need to use UPnP technology directly, providing interfaces to detect, manage and configure the NAT device.

The NAT Traversal API

When a network application needs to detect the presence of a NAT device and adjust behavior of that device, the application can use the NAT Traversal API offered in Windows (fully documented in the Platform SDK) to provide the following functionality:

•	Determine if a NAT is present
•	Get the external IP address of the NAT.
•	Get the static port mapping information for a specific external port, if it is mapped.
•	Add a static port mapping, unless the external port is previously assigned.
•	Enable or disable a specific port mapping without deleting it
•	Edit the user-friendly description of a static port mapping
•	Delete a static port mapping.
•	Obtain a list of static port mappings for the local network.

With this functionality, applications can work around many of the problems created by the presence of NAT. Note that Windows NAT traversal APIs support port mappings only of infinite duration, otherwise known as static port mapping, at this time.

NAT Traversal APIs in Windows XP

NAT Traversal APIs are installed by default on Windows XP. These APIs also can be installed on machines running Windows Me and Windows 98 by using a tool on the Windows XP CD called the "Network Setup Wizard". The NAT Traversal APIs also require users to install Internet Explorer version 6.0 for the additional XML parser support provided.

NAT Traversal is not currently supported on Windows 2000.

Supporting NAT Traversal in Internet Gateways

Internet gateways support NAT traversal by supporting the Internet Gateway Device (IGD) specification defined by the Internet Gateway Working Committee of the Universal Plug and Play Forum. Gateways vendors also should be aware that NAT traversal APIs in Windows make the following assumptions about IGDs.

•	IGDs only advertise one external interface at a time. Though it is technically acceptable for Internet Gateway Devices to advertise multiple external interfaces, the NAT Traversal APIs will only use the first one.
•	IGDs support port mappings that allow any remote IP address to send packets to internal clients.
•	IGDs support port mappings with the broadcast address listed as the client
•	IGDs support different numbers for the external port of the NAT and internal port of the client.
•	IGDs will advertise with a version number of 1.
•	Static port mappings (or port mappings with a duration set to infinity) will persist indefinitely, surviving reboots, IP address changes, and the presence of the client on the server.

As this document is written, several leading manufacturers already have announced plans to begin shipping Internet gateway devices that support UPnP technology methods and that work with the Windows NAT Traversal APIs. This is a significant step forward for the industry and for customers.

As more manufacturers of Internet gateway devices understand the benefits of using UPnP technology to address this issue and as more consumer and small business users become aware of the issues associated with NAT and the viability of these UPnP certified NAT traversal solutions, there is an expectation that UPnP certification for NAT traversal will become a checkbox item or market requirement for devices in this category.

Internet gateway vendors should become members of the UPnP Forum to learn how to make their Internet Gateway Device compliant with UPnP technology.

It should be noted that Internet Connection Sharing on Windows XP supports version 0.9 of the UPnP IGD standard. It is anticipated that version 1.0 will be compatible with version 0.9.

How Applications Make Use of NAT Traversal

How an application uses NAT Traversal will depend upon several factors, including how long-lived a port mapping needs to be and whether the port is used by multiple clients or services. It is very important that applications clean up any static port mappings they create to avoid orphaned mappings and depletion of ports for use by other applications.

If an application is a network service, like a Web server, and requires the use of a well known port for the duration of its life time, its installation program can use the NAT Traversal APIs to configure a static port mapping. Assuming that other applications, network administrators, the network topology remains constant and clean-up mechanisms leave the mapping alone, external clients will be able to contact the service for the life of the service. The application's uninstall service is responsible for deleting this mapping. In the event of a crash, the static port mappings will persist in the absence of the service. If the external IP address changes, the static port mapping will automatically pick up the change.

If the application is not always going to be running, or is less trusting of the network to maintain its static port mappings, it might reserve a particular well known port every time it launches and return the resource every time it shuts down. This can be done by running a script in parallel. An alternative to adding and deleting the port mapping is for the application to enable and disable the mapping as appropriate. The application can also leave the static port mapping up all the time and simply refresh the mapping whenever the application launches.

Again, if the external IP address changes the static port mapping automatically picks up the change.

If multiple applications on different clients on the private network use the same internal port number, the applications will require modification to support multiple clients running. Only a single client can use this internal port number for an external port mapping. The recommended behavior here is first client wins. The other clients should request asymmetric port mappings where the internal port number is different than the external port.

There is a special case where multiple clients can listen on the same external port for the sole purpose of being discovered by remote hosts. Incoming packets can be translated to use a broadcast address for the internal client IP address, instead of a particular clients address. Clients that are listening on that port will be able to reply by initiating their own connection to the remote host. This in is not recommended for general use, because incoming packets to this address will be received by and affect every client on the network.

If a service needs to listen to a random port for a short time, it should request a static port mapping from within the application and not with a script. It should clean up after itself as soon as it is done (delete the mapping). The application should keep a record of its outstanding port mappings. This way if the application where to crash without closing the mappings, it will be able to retrieve the information necessary to clean up the port mappings the next time it is launched.

If an application should leave the network without cleaning up its port mappings, the mappings will remain and cleanup responsibility will fall on the user. There is currently no clean up mechanism in Windows, as it is difficult to tell when an application is done using a mapping.

Limitations of NAT Traversal

While NAT Traversal solves several problems associated with connecting through NAT devices, several issues remain or exist as a result of NAT Traversal. These issues include:

•	NAT traversal has an open trust model. This means that all application on the private network have access to all the port mappings on a NAT. This allows for a great amount of flexibility of multiple points of administration, but applications do not have exclusive ownership of their mappings.
•	Conflict resolution is the responsibility of applications. If an application tries to map a port that is already mapped to another client, it is up to the application to either find another port or overwrite the application.
•	NAT traversal does not solve the problem of an ISP distributing private addresses and using NAT to let clients connect. In this case the NAT is outside of the Internet Gateway Device, actually sitting within the service provider's network. NAT traversal within the home or small business will fail if the NAT on the client's network is behind another such NAT. As a result, Internet service providers are encouraged not to deploy NAT within their networks.
•	Applications don't get NAT traversal for free; they will have to be modified to call APIs or ship with scripts to make the solution happen. This is a manageable development effort for most developers, particularly considering that once these NAT traversal mechanisms have been incorporated into an application, the application can work automatically with a variety of Internet gateway devices.
•	Applications are responsible for cleaning up after themselves when they are done with a port mapping. Static mappings persist indefinitely and are most appropriately used by services that intend to listen on well-known ports for the life of the application.
•	The Internet gateway providing the NAT must support Universal Plug and Play Internet Gateway Device Spec version of at least .9.

Conclusion

NAT is an IETF-approved solution to the problem of IPv4 name space exhaustion. Internet gateways that use NAT are often used in homes and small offices. They are used because they are cheap, easy to manage, and don't require users to install special software.

The downside to using NAT is that many chat, multiplayer games and peer-to-peer applications break. This is because their network protocols make assumptions about the network architecture that are no longer true.

NAT Traversal provides a way for applications to discover the presence of the NAT device, discover the shared, globally routable IP address and configure static port mappings to solve some of the connectivity problems. The NAT traversal solution does not solve all of the problems associated with NAT, but alleviates some of the problems.

Key takeaways from this paper should be that:

•	Internet Gateway Device vendors should implement support for UPnP technology in their devices to support NAT Traversal.
•	Network application developers should use the Windows NAT Traversal APIs to detect the presence of NAT and enable their applications to traverse the NAT when necessary.
•	Consumers should use Internet gateway devices that support UPnP technology and NAT Traversal to ensure the best application behavior.
•	DSL and cable modem service providers should specify, sell, and lease Internet gateway devices that support UPnP technology for NAT traversal.

NAT Traversal in some form will likely continue until IPv6 eliminates the need for NAT.