Zero Configuration Networking: The Definitive Guide

5.6. NAT Port Mapping Protocol (NAT-PMP)

The politics and economics of Internet access have made Internet addresses a rationed resource. Originally, Internet Service Providers (ISPs) sought to charge customers varying amounts depending on how many computers, printers, and other network devices they had. The logic was that anyone who had more than one computer, or owned a network printer, must be a business, and therefore should be charged a lot more for the exact same speed of network connectivity. Customers, naturally, were not enthusiastic about the idea of paying a printer tax to their ISP. NAT was invented and allowed customers to have any number of computers and other devices appear to their ISP as just a single device with a single IP address. ISPs countered by checking that the Ethernet address of the visible device matched the Ethernet address of the single computer the customer had signed up for. NAT vendors countered by adding configuration options to allow customers to set their NAT gateway to present a spoof Ethernet address matching the one the ISP was looking for. Around this time, the ISPs gave up the arms race, leaving us with today's situation: most people get just a single IP address from their ISP, and if they want to use more than one computer, they have to use NAT to share that one IP address.

One thing that NAT vendors initially were not keen to point out is that NAT's address sharing only half workedit worked for outgoing connections but not for incoming ones. However, since at the time all that most Internet users knew about was the Web and email, they never noticed. Later, when security problems on the Internet became rife, some smart marketing people did what smart marketing people dothey recast NAT's deficiency as a feature. It was good, they said, that NAT didn't work for incoming connections, because that protected you from all the bad people out there. (Similar to how a telephone that was unable to receive incoming calls would protect you from receiving telemarketing calls.)

This is the world we find ourselves in today. What makes this a little sad is that the Internet is capable of much more than just the Web and email, but the prevalence of NAT makes many of those new uses difficult or impossible. Expert users may know how to set up manual port mappings for inbound connections, but the other 99% of users don't. If you want to make a new product that communicates peer-to-peer or otherwise receives inbound connections, then requiring your customers to set up manual port mappings is a recipe for bankruptcy. iChat AV on the Macintosh, for example, has to go to great lengths and perform fancy tricks to get peer-to-peer audio and video to work without manual port mappings and requires a special server on the public Internet to facilitate this; even then, it still doesn't work with all NAT gateways.

NAT Port Mapping Protocol (NAT-PMP) allows client software that needs inbound port mappings to request them, and, furthermore, if the client crashes or is disconnected or otherwise goes away, those port mappings are automatically tidied up. Of course, existing software that doesn't need or want inbound port mappings doesn't request them and doesn't get them.

NAT-PMP is described at http://files.dns-sd.org/draft-cheshire-nat-pmp.txt.

5.6.1. Network Address Translation

The success of web browsing, email, and instant messaging is due, in large part, to the extent to which the end user has been shielded from the underlying protocols. When casual users click on a link in a web browser, they probably do not stop to consider that they have just issued a request and that the server responding to that request must know where to send the response. They almost certainly don't consider how this works when they have a private IP address, and all the packets are being modified by the NAT gateway before being sent out to the rest of the Internet.

Figure 5-3 shows the configuration page for a typical NAT gateway. Its real public Internet IP address is 69.3.204.77, but on the local network it uses the private address 192.168.1.1. The public IP address 69.3.204.77 is globally uniqueat any moment in time, only one computer on the Internet on the entire planet has that address. On the other hand, at any moment in time, there are thousands, maybe millions, of devices all thinking they have the IP address 192.168.1.1.

A computer on the local area network (LAN) connected to this NAT gateway may have an IP address such as 192.168.1.151. As with the address 192.168.1.1, there are probably thousands of computers around the world using the address 192.168.1.151 on their own LANs. If you or I were to send a packet addressed to 192.168.1.151, it would certainly not arrive at any machine outside of the LAN we were currently connected to.

When computer 192.168.1.151 sends out an outgoing TCP request to some machine on the Internet, the NAT gateway rewrites the source address in the packet from private address 192.168.1.151 to public address 69.3.204.77 (which is the IP address of the NAT gateway in this example). So that it can make sense of the replies that come back, it also rewrites the port number to a unique one that it's not already using. Now, the outgoing packet has a globally meaningful source address, and when the machine on the Internet replies, the replies will successfully make it back to the NAT gateway. When the NAT gateway gets the reply, it looks up the destination port number in its table to see which LAN client this packet belongs to. It then rewrites the destination address and port number back to what the local client is expecting, corrects the packet checksum, and forwards it on.

The reason this works is because when a local client contacts an external server, it sends out an outgoing TCP connection request. The NAT gateway gets to see that outgoing TCP packet, and from the data in the packet header, the NAT gateway can glean the information it needs to make an entry in its mapping table.

In contrast, when a local machine listens for incoming connections, it is a passive operation. It doesn't generate any packets or otherwise cause any activity that could allow the NAT gateway to work out what it was required to do. Even supposing the NAT gateway was able somehow to make the required mapping, external clients still couldn't connect to that service without knowing the correct public IP address and port number to use.

Accordingly, we have two problems to solve. The local machine has to inform the NAT gateway of its desire to receive incoming connections, and then, having made a port mapping, it has to place that information somewhere external clients can get at it, so that they know which address and port number they should use to access the service.

The public place to store the service information, you should not be surprised to hear, is the global DNS system, using DNS-UL. The public address is stored in an address record, and the port number is stored in an SRV record describing the service.

5.6.2. Obtaining the Public Address

Before the local machine can perform a Secure DNS Dynamic Update to update its address record to give the NAT's public IP address, it first has to find out what that address is. It does this bysimply enoughasking the NAT gateway. The local machine sends a UDP request packet to port 5351 of its default gateway address. This protocol is only designed for the usual case where the NAT gateway is the one-and-only gateway on a small, single-subnet home network. The UDP packet contains two bytes of data. The first byte is the protocol version (currently 0) and the second byte is the opcode. Opcode 0 requests the public IP address.

Every packet used in the NAT Port Mapping Protocol starts with an eight-bit version followed by an eight-bit operation code. Opcodes 0-127 are used for client requests and opcodes 128-255 are used for the respective corresponding responses from the gateway. Responses also always contain two additional fields: a 16-bit result code in network byte order with success represented by a response code of 0, and a "seconds since reboot" field. Clients use the "seconds since reboot" field to detect if the gateway crashes, is power-cycled, or otherwise restarted. If this happens, your typical NAT gateway will completely forget any mappings it may have created (yet another of the many shortcomings of NAT gateways), so this is a valuable hint to tell clients that they should reissue all their mapping requests to recreate their mappings.

If, after 250 ms, the client has not received a response from the gateway device, it should reissue its request. In the absence of a response, this process is repeated, with the interval doubling each time until either a response is received or two minutes have passed. If two minutes passes without a response, then the client can conclude that this gateway does not support NAT port mapping protocol.

The first byte of the response is again 0 for the version and, this time, the second byte is 128, the response code corresponding to request code 0. The next two bytes contain the result code and the final four bytes contain the public IP address. The possible result codes are:

0

Success

1

Unsupported Version

2

Not Authorized/Refused (supported but disabled)

3

Network Failure

4

Out of resources (e.g., no more mappings currently available)

5

Unsupported opcode

If the result code is nonzero, the value stored in the public IP address field is undefined and must be disregarded by the client. In the future, other error codes may be added; any unknown nonzero result must be treated by the client as a permanent error.

NAT gateways often obtain their public IP address through DHCP or some other method that does not guarantee it will remain the same. If the public IP address changes, local machines will need to know to update their DNS records to show the new address. To let them know this, when its public IP address changes, the NAT gateway alerts devices on the local network by sending a series of gratuitous opcode 128 response packets to the all-hosts link-local multicast address 224.0.0.1 on port 5351, giving the new public IP address. This notification is sent 10 times, with an interval between the first two notifications of 250 ms and, as before, the interval between subsequent notifications doubling.

5.6.3. Creating and Destroying a Mapping

Once the client has determined its public IP address, the next step is to request a public port number at this public address, to be used to receive inbound connection requests. The client initiates a request for a mapping by sending a UDP request packet to port 5351 on the default gateway, with the following format:

• The first field is an eight-bit version code, currently set to 0.

• The second field is an eight-bit opcode that is set to 1 if the client is requesting a map to a UDP port and set to 2 if the client is requesting a map to a TCP port. A NAT device that implements this protocol must be able to create TCP-only and UDP-only port mappings. If a device can only create these port mappings in pairs, it should not implement this protocol.

• The third field is a 16-bit reserved field that must be set to 0.

• The fourth field is 16 bits and contains the number of the private port that the device currently uses for the service.

• The fifth field is 16 bits and is used for the number of the requested public port that will be mapped to the private port. Often, this requested port is the same value as the private port. If there is no preference, then this field should be set to 0.

• The sixth field is 32 bits and contains the requested lifetime in seconds. The recommended value for this field is 3,600 seconds (one hour).

As before, the client sends the request and waits for a response. If no response is received within 250 ms, the request is sent again. The client repeats this process with the interval between attempts doubling each time until either a response is received or until two minutes after the first request was sent. If no response is received in two minutes, an error message should be logged and the client should stop issuing requests.

The response from the NAT device looks very similar to the request sent by the client behind the NAT.

• The first field is the eight-bit version code that is still set to 0.

• The second field is an eight-bit opcode that should be 128 greater than the opcode sent by the client. In other words, the value should be 129 for a UDP port and 130 for a TCP port.

• The third field is a 16-bit result code. As before, success is indicated by a 0 in this field. The values of the result code are listed in the preceding section.

• The fourth field repeats the private port sent in the request.

• The fifth field is 16 bits and contains the number of the mapped port. This is the value that the service will use together with the public IP address to advertise the service. If no public ports are available then the result code of 4 will indicate a lack of resources.

• The sixth field is 13 bits and is used to convey the actual lifetime of the mapping. This value is allowed to be equal to or less than the value requested by the client. It is not recommended that a lease be granted that is greater than that requested by the client.

The client should begin trying to renew the mapping halfway through the actual lifetime. The renewal packet is identical to the initial request packet, except that the fifth field, which contains the requested public port, is set to the actual port number that was allocated, rather than the port number the client may have originally requested (if different). Making the renewal packet identical to a request packet has a couple of useful properties. If the NAT gateway response to the first request packet is lost, then the client's retransmission of the request packet looks, to the NAT gateway, just like a renewal and is handled correctly. Conversely, if the NAT gateway crashes or is rebooted, then the client's renewal packet looks, to the NAT gateway, just like a brand new request. Since the client is requesting the same previously assigned public port number, the NAT gateway ends up re-creating the lost mapping. This makes the protocol self-healing in the face of packet loss and gateway reboots.

• If a client is unsuccessful in renewing a mapping before its lifetime expires, then the mapping is deleted.

• If a client's DHCP lease times out, the gateway device should also delete any mappings belonging to that client. Stale mappings pointing to a private IP address could potentially direct traffic to a new device that is assigned that IP address by the DHCP server. Since the NAT gateway and DHCP server are normally the same box, this is often easy to do.

• A client can request explicit deletion of a mapping by sending a request to the NAT device identical to the initial request, except that the requested lifetime in seconds is set to 0.

If the request to destroy a mapping is unsuccessful, the result code in the response is not zero. One example might be that the client attempts to delete a permanent port mapping manually configured by the human operator. In this case, the response code is 2 to indicate the request is not authorized.

If a mapping is successfully destroyed, the response packet has a result code of 0, contains the private and public ports of the destroyed mapping, and has a lifetime of 0. In the event that a NAT device receives a request to destroy a mapping that does not exist, it issues a response as if an actual mapping were successfully destroyed. This also is to guard against packet loss. For example, suppose the NAT gateway receives a mapping deletion request and successfully deletes the mapping, but the response packet is lost. When the client retransmits its request, not knowing the mapping was actually successfully deleted already, the NAT gateway needs to send it a "no error" successful response to assure it that the mapping was, as it requested, successfully deleted.