Document: draft-nat-port-mapping-00.txt                       July, 2004
Status: WORK IN PROGRESS

            Network Address Translation Port Mapping Protocol

                   <draft-nat-port-mapping-00.txt>

Abstract

   This document describes a protocol for automating the process of
   creating Network Address Translation (NAT) port mappings. This basic
   protocol allows a client to retrieve the public IP address of the NAT
   device and create a port mapping to allow incoming connections and
   peer-to-peer communications.


Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC 2119].


1. Introduction

   Network Address Translation (NAT) is a method of sharing one public
   internet address with a number of devices. A full description of NAT
   is beyond the scope of this document. The following quick overview
   will cover the bits relevant to this port mapping protocol. For more
   information on NAT, see RFC 3022 [RFC 3022].

   NATs have one or more public IP addresses. A private network is setup
   behind the NAT. Devices behind the NAT are assigned private addresses
   and the private address of the NAT device is used as the gateway.

   When a packet from any device behind the NAT is sent to an address on
   the internet, the packet first passes through the NAT box. The NAT
   box looks at the source port and address. In some cases, a NAT will
   also keep track of the destination port and address. The NAT then
   creates a mapping from the private address and private port to a
   public address and public port if a mapping does not already exist.
   The NAT box replaces the private address and port with the public
   entries from the mapping and sends the packet on to the next gateway.

   When a packet from any address on the internet is received by the
   NAT, the NAT will look up the destinatination port (public port) in
   the list of mappings. If an entry is found, it will contain the
   private address and port that the packet should be sent to. The NAT
   device will then rewrite the destination address and port with those
   from the mapping. The packet will then be forwarded to the new
   destination addresses. If the packet did not match any mapping, the
   packet will most likely be dropped. Various NATs implement different
   strategies to handle this. The important thing to note is that if
   there is no mapping, the NAT does not know which private address the
   packet should be sent to.

   Mappings are usually created by outbound traffic. There are a few
   exceptions. Some NATs may allow permanent mappings that map a public
   port to a specific private ip address and port. Such a mapping allows
   incoming connections to the device with that private address. Some
   NATs also implement a default mapping where any inbound traffic that
   does not match a mapping will always be forwarded to a specific
   private address. Both types of mappings are usually setup manually
   through some configuration tool.


2. Packet Format

   The protocol is a simple protocol that runs over UDP. Every packet
   starts with a 8 bit version followed by a 8 bit operation code. This
   document specifies version 0 of the protocol. Opcodes between 0 and
   127 are client requests. Opcodes from 128 to 255 are server
   responses. Responses always contain a 16 bit result code in network
   byte order. A result code of zero indicates success.


2.1 Determining the Public Address

   To determine the public address, the client behind the NAT sends the
   following UDP payload to port [TBD] of the configured gateway address:

   0                   1             
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers = 0      | OP = 0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This packet is sent by clients to determine the public IP address and
   to determine whether or not the gateway supports this protocol.

   The NAT device MUST generate a response with the following format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers = 0      | OP = 128 + 0  | Result Code                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Public IP Address (a.b.c.d)                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This response indicates that the NAT device implements this version
   of the protocol and returns the public IP address of the NAT device.
   If the result code is non-zero, the value of Public IP Address is
   undefined.

   When the public IP address changes, the NAT device SHOULD send a
   subnet broadcast to UDP port [TBD] with the format above to notify
   the devices of a new public IP address.


2.2 Creating a Mapping

   To create a mapping, the client sends a UDP packet to port [TBD] of
   the gateway address with the following format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers = 0      | OP = x        | Reserved (MUST be zero)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Requested Public Port          | Private Port                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Requested Lifetime in Seconds                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Opcodes supported:
   1 - Map UDP
   2 - Map TCP
   3 - Map both UDP and TCP

   When sending the packet, the reserved field MUST be set to zero. When
   receiving, the reserved field SHOULD be ignored.

   The NAT device responds with the following packet format:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vers = 0      | OP = 128 + x  | Result Code                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Private Port                  | Mapped Public Port            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Lifetime in Seconds                                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The 'x' in the OP field may not match what the client requested. Some
   NAT boxes always map both ports together, so the client may request
   OP=1 or OP=2 but get a reply with OP=128+3. To put it another way:
   the NAT box MAY upgrade a 'map UDP' request or a 'map TCP' request to
   'map both', but it MUST NOT downgrade a 'map both' request to a
   lesser request.

   The client normally requests the public port matching the private
   port. If that public port is not available, the NAT device MUST
   return a public port that is available or return an error code if no
   ports are available.

   In the case of a 'map both' request, the NAT device MUST map both or
   neither. If the requested public port is available for one transport
   protocol but not the other, then the NAT device MUST return a public
   port that is available for both, or return an error code. The NAT
   device MUST NOT return a downgraded response where only one of the
   two ports was mapped.

   The source address of the packet MUST be used for the private address
   in the mapping. Devices behind the NAT may not create mappings for
   other devices.

   The NAT device SHOULD NOT accept mapping requests destined to the NAT
   device's public IP address. Only packets with a destination address
   matching the private address(es) of the NAT device should be allowed.

   The lifetime is an unsigned integer in seconds. The NAT device may
   reduce the lifetime from what the client requested.

   The client should begin trying to renew the mapping halfway to expiry
   time, like DHCP. When renewing, the client SHOULD set the Requested
   Public Port to what the router previously mapped. If the router
   crashes or is rebooted, this helps the router recover its mapping
   state. The mapping type SHOULD match what the router previously
   mapped as well.


2.3 Destroying a Mapping

   A mapping is destroyed by sending a message to the NAT device to
   perform the mapping with the Requested Lifetime in Seconds set to 0.
   If the NAT device returned 'mapped both (128 + 3)', the client MUST
   send a request to destroy the UDP and TCP mapping by sending a 'map
   both' request. When deleting a mapping, the Requested Public Port is
   undefined.


2.4 Result Codes

   Currently defined result codes:
   0 - Success
   1 - Unsupported Version
   2 - Not authorized/refused (box supports mapping, but user has
       turned feature off)
   3 - Network Failure (e.g. NAT box itself has not obtained a DHCP
       lease)
   4 - Out of resources (NAT box cannot create any more mappings at
       this time)
   5 - Unsupported opcode

   If the result code is not zero, the format of the packet following
   the result code may truncated. For example, if the client sends a
   request to the server with an opcode of 17 and the server does not
   recognize that opcode, the server SHOULD respond with a message where
   the opcode is 17 + 128 and the result code is 5 (opcode not
   supported). Since the server does not understand the format of opcode
   17, it may not know what to place after the result code. In some
   cases, relevant data may follow the opcode to identify the operation
   that failed. For example, a client may request a mapping but that
   mapping may fail due to resource exhaustion. The server SHOULD
   respond with the result code to indicate resource exhaustion (4)
   followed by the requested port mapping so the client may identify
   which operation failed.


3. UNSAF Considerations

   The document IAB Considerations for UNSAF Across NAT [RFC 3424]
   covers a number of issues when working with NATs. RFC 3424 outlines
   some requirements for any document that attempts to work around
   problems associated with NATs. This section addresses those
   requirements.


3.1 Scope

   This protocol addresses the needs of TCP and UDP transport peers that
   are separated from the public internet by exactly one NAT. Such peers
   must have access to some form of directory server for registering the
   public IP address and port at which they can be reached.


3.2 Transition Plan

   Any client making use of this protocol should implement IPv6 support.
   If a client supports IPv6 and is running on a device with a global
   IPv6 address, that IPv6 address should be preferred to the IPv4
   public address using this NAT mapping protocol. In case other clients
   do not have IPv6 connectivity, both the IPv4 and IPv6 addresses
   should be registered with whatever form of directory server is used.
   Preference should be given to IPv6 addresses when available. By
   implementing support for IPv6 and using this protocol for IPv4,
   vendors can ship products today that will work under both scenarios.
   As IPv6 is more widely deployed, clients of this protocol following
   these recomendations will transparently make use of IPv6.


3.3 Failure Cases

   Aside from NATs that do not implement this protocol, there are a
   number of situations where this protocol will not work. Additional
   work not covered in this document may be done to cover the first two
   failure cases.


3.3.1 NAT Behind NAT

   Some people may only receive a NAT address from an ISP. Though such a
   thing seems ridiculous, such situations may exist. In addition, some
   people may double NAT, perhaps by choice or perhaps by accident. It
   should be possible for a NAT device to implement not only a server
   but a client. A NAT device that detects it is behind a NAT may
   attempt to use this protocol as a client to effectively relay mapping
   requests to the next NAT. Upon creating a mapping internally, the NAT
   then forwards the request to the next NAT, using the values it mapped
   as public port as the private port. In theory, if all the NATs
   between a client and the real internet supported this and the
   resources were available, a client behind multiple NATs could be made
   to work.


3.3.2 NATs with Multiple Public IP Addresses

   If a NAT maps private addresses to multiple public addresses, it may
   not immediately work with the protocol described above. The NAT may
   sub-divide the private network to make the protocol work, always
   mapping specific private addresses to specific public addresses. For
   example: If the NAT device had 4 public IP addresses, 192.0.2.5,
   192.0.2.6, 192.0.2.7, and 192.0.2.8, the NAT could divide the network
   in to four segments. With a private network o 10.0.1.0/24, private
   address 10.0.1.2 could always map to address 192.0.2.5. Private
   address 10.0.1.253 would always map to 192.0.2.8. The only other
   modification required would be to eliminate the broadcast if the
   public address changes. A unicast to each address that has received a
   message indicating the public IP address that changed could be used
   instead.


3.3.3 NATs and Routed Private Networks

   In some cases, a large network may be subnetted. Some sites may
   install a NAT device and subnet the private network. Such subnetting
   breaks this protocol because the router address is not necessarily
   the address of the device performing NAT.

   Addressing this problem is not a high priority. Any site with the
   resources to setup such a configuration should have the resources to
   add manual mappings or attain a range of globally unique addresses.

   Not all NATs will support this protocol. In the case where a client
   is run behind a NAT that does not support this protocol, the software
   relying on the functionality of this protocol may be unusable.


3.3.4 Communication Between Hosts Behind the Same NAT

   The proposed solution above may fail in some cases where two devices
   attempting to communicate are behind the same NAT. In this case, both
   devices will have a mapping to the same public address and different
   ports. The devices may send packets to the public IP address of the
   NAT and the public port that corresponds to the mapping for the other
   device. For example: Host 10.0.1.5 wants to communicate with host
   10.0.1.7. Both hosts are behind the same NAT. The NAT has a public IP
   address of 192.0.2.15. Host 10.0.1.7 has requested a mapping from the
   NAT for 192.0.2.15:80 to map to 10.0.1.7:80. Host 10.0.1.7 has
   registered this through some other directory service. Host 10.0.1.5
   retrieves this information and sends a packet to 192.0.2.15:80. Some
   NATs handle this by forwarding the packet to 10.0.1.7:80. Some NATs
   do not handle this case.


3.3.5 Non UDP/TCP Transport Traffic

   Any communication over transport protocols other the TCP and UDP will
   not be served by this protocol. Examples are Generic Routing
   Encapsulation (GRE), Authentication Header (AH) and Encapsulating
   Security Payload (ESP).


3.4 Long Term Solution

   As IPv6 is deployed, clients of this protocol supporting IPv6 will be
   able to bypass this protocl and the NAT when communicating with other
   IPv6 devices. In order to ensure this transition, any client
   implementing this protocol should also implement IPv6 and use this
   solution only when IPv6 is not available to both peers.


3.5 Existing Deployed NATs

   Existing deployed NATs will not support this protocol. This protocol
   will only work with NATs that are upgraded to support it.


4. Security Considerations

   Some people use NAT as a way to "secure" their network. This is
   similar to ripping the ringer out of your phone to stop
   tele-solicitors. It is unfortunately a common practice. Supporting a
   protocol for poking a hole through the NAT may be viewed by some as a
   security hole. To appease those who enjoy being second class citizens
   on the internet, any NAT device implementing this protocol SHOULD
   have some mechanism to disable support for this protocol. The
   protocol SHOULD be enabled by default. Every NAT device uses a
   different interface for configuration. A vendor relying on this
   protocol for their product to work behind a NAT would be unable to
   give a user directions to enable this protocol.


5. Copyright

   Copyright (C) 2004 Apple Computer, Inc.
   All Rights Reserved.


6. References

   [RFC 2119] RFC 2119 - Key words for use in RFCs to Indicate
              Requirement Levels

   [RFC 3022] RFC 3022 - Network Address Translator

   [RFC 3424] RFC 3424 - IAB Considerations for UNilateral Self-Address
              Fixing (UNSAF) Across Network Address Translation