< draft-cheshire-nat-pmp-01.txt   draft-cheshire-nat-pmp-02.txt >
Document: draft-cheshire-nat-pmp-01.txt Stuart Cheshire Document: draft-cheshire-nat-pmp-02.txt Stuart Cheshire
Internet-Draft Marc Krochmal Internet-Draft Marc Krochmal
Category: Standards Track Apple Computer, Inc. Category: Standards Track Apple Computer, Inc.
Expires 10th February 2007 Kiren Sekar Expires 14th March 2007 Kiren Sekar
Sharpcast, Inc. Sharpcast, Inc.
10th August 2006 14th September 2006
NAT Port Mapping Protocol (NAT-PMP) NAT Port Mapping Protocol (NAT-PMP)
<draft-cheshire-nat-pmp-01.txt> <draft-cheshire-nat-pmp-02.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
For the purposes of this document, the term "BCP 79" refers For the purposes of this document, the term "BCP 79" refers
exclusively to RFC 3979, "Intellectual Property Rights in IETF exclusively to RFC 3979, "Intellectual Property Rights in IETF
Technology", published March 2005. Technology", published March 2005.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes a protocol for automating the process of This document describes a protocol for automating the process of
creating Network Address Translation (NAT) port mappings. Included creating Network Address Translation (NAT) port mappings. Included
in the protocol is a method for retrieving the public IP address of a in the protocol is a method for retrieving the public IP address of
NAT gateway, thus allowing a client to make this public IP address a NAT gateway, thus allowing a client to make this public IP address
and port number known to peers that may wish to communicate with it. and port number known to peers that may wish to communicate with it.
This protocol is implemented in current Apple products including This protocol is implemented in current Apple products including
Mac OS X, Bonjour for Windows, and AirPort wireless base stations. Mac OS X, Bonjour for Windows, and AirPort wireless base stations.
1. Introduction 1. Introduction
Network Address Translation (NAT) is a method of sharing one public Network Address Translation (NAT) is a method of sharing one public
internet address with a number of devices. This document is focused internet address with a number of devices. This document is focused
on what "IP Network Address Translator (NAT) Terminology and on what "IP Network Address Translator (NAT) Terminology and
Considerations" [RFC 2663] calls "NAPTs" (Network Address/Port Considerations" [RFC 2663] calls "NAPTs" (Network Address/Port
skipping to change at page 3, line 39 skipping to change at page 3, line 39
packet with a version number other than 0, MUST return result code 1 packet with a version number other than 0, MUST return result code 1
(Unsupported Version). (Unsupported Version).
Opcodes between 0 and 127 are client requests. Opcodes from 128 to Opcodes between 0 and 127 are client requests. Opcodes from 128 to
255 are server responses. Responses always contain a 16 bit result 255 are server responses. Responses always contain a 16 bit result
code in network byte order. A result code of zero indicates success. code in network byte order. A result code of zero indicates success.
Responses also contain a 32 bit unsigned integer corresponding to the Responses also contain a 32 bit unsigned integer corresponding to the
number of seconds since the NAT gateway was rebooted or since its number of seconds since the NAT gateway was rebooted or since its
port mapping state was reset. port mapping state was reset.
This protocol SHOULD only be used when the client determines that its This protocol SHOULD only be used when the client determines that
primary source IPv4 address is in the range of private IP addresses its primary IPv4 address is in one of the private IP address ranges
defined in RFC 1918. This includes the address ranges 10/8, defined in "Address Allocation for Private Internets" [RFC 1918].
172.16/12, and 192.168/16. This includes the address ranges 10/8, 172.16/12, and 192.168/16.
Clients always send their Port Mapping Protocol requests to their Clients always send their Port Mapping Protocol requests to their
default gateway, as learned via DHCP [RFC 2131], or similar means. default gateway, as learned via DHCP [RFC 2131], or similar means.
This protocol is designed for small home networks, with a single This protocol is designed for small home networks, with a single
logical link (subnet) where the client's default gateway is also the logical link (subnet) where the client's default gateway is also the
NAT translator for that network. For more complicated networks where NAT translator for that network. For more complicated networks where
the NAT translator is some device other than the client's default the NAT translator is some device other than the client's default
gateway, this protocol is not appropriate. gateway, this protocol is not appropriate.
3.1 Requests and Responses 3.1 Requests and Responses
skipping to change at page 4, line 21 skipping to change at page 4, line 21
requests (e.g. on boot, wake from sleep, network connection, etc.) requests (e.g. on boot, wake from sleep, network connection, etc.)
it SHOULD queue them and issue them serially one at a time. Once the it SHOULD queue them and issue them serially one at a time. Once the
NAT gateway responds to one request the client machine may issue the NAT gateway responds to one request the client machine may issue the
next. In the case of a fast NAT gateway, the client may be able to next. In the case of a fast NAT gateway, the client may be able to
complete requests at a rate of hundreds per second. In the case of complete requests at a rate of hundreds per second. In the case of
a slow NAT gateway that takes perhaps half a second to respond to a slow NAT gateway that takes perhaps half a second to respond to
a NAT-PMP request, the client SHOULD respect this and allow the a NAT-PMP request, the client SHOULD respect this and allow the
NAT gateway to operate at the pace it can manage, and not overload NAT gateway to operate at the pace it can manage, and not overload
it by issuing requests faster than the rate it's answering them. it by issuing requests faster than the rate it's answering them.
To determine the puclic IP address or request a port mapping,
a NAT-PMP client sends its request packet to port 5351 of its
configured gateway address, and waits 250ms for a response. If no
NAT-PMP response is received from the gateway after 250ms, the client
retransmits its request and waits 500ms. The client SHOULD repeat
this process with the interval between attempts doubling each time.
If, after sending its 9th attempt (and then waiting for 64 seconds),
the client has still received no response, then it SHOULD conclude
that this gateway does not support NAT Port Mapping Protocol and
MAY log an error message indicating this fact. In addition, if the
NAT-PMP client receives an "ICMP Port Unreachable" message from the
gateway for port 5351 then it can skip any remaining retransmissions
and conclude immediately that the gateway does not support NAT-PMP.
As a performance optimization the client MAY record this information
and use it to suppress further attempts to use NAT-PMP, but the
client should not retain this information for too long. In
particular, any event that may indicate a potential change of gateway
or a change in gateway configuration (hardware link change
indication, change of gateway MAC address, acquisition of new DHCP
lease, receipt of NAT-PMP announcement packet from gateway, etc.)
should cause the client to discard its previous information regarding
the gateway's lack of NAT-PMP support, and send its next NAT-PMP
request packet normally.
3.2 Determining the Public Address 3.2 Determining the Public Address
To determine the public address, the client behind the NAT sends the To determine the public address, the client behind the NAT sends the
following UDP payload to port 5351 of the configured gateway address: following UDP payload to port 5351 of the configured gateway address:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers = 0 | OP = 0 | | 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. After
sending the request, the client then waits for the NAT gateway to
respond. If after 250ms, the gateway doesn't respond (and doesn't
generate "ICMP Port Unreachable" messages), the client SHOULD
re-issue its request. The client SHOULD repeat this process with the
interval between attempts doubling each time. If, after two minutes,
the client has not received any response, then it SHOULD conclude
that this gateway does not support NAT Port Mapping Protocol and MAY
log an error message indicating this fact.
A compatible NAT gateway MUST generate a response with the following A compatible NAT gateway MUST generate a response with the following
format: format:
0 1 2 3 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 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 | | Vers = 0 | OP = 128 + 0 | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch | | Seconds Since Start of Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 26 skipping to change at page 5, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This response indicates that the NAT gateway implements this version This response indicates that the NAT gateway implements this version
of the protocol and returns the public IP address of the NAT gateway. of the protocol and returns the public IP address of the NAT gateway.
If the result code is non-zero, the value of Public IP Address is If the result code is non-zero, the value of Public IP Address is
undefined (MUST be set to zero on transmission, and MUST be ignored undefined (MUST be set to zero on transmission, and MUST be ignored
on reception). on reception).
The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field
with the time elapsed since its port mapping table was initialized on with the time elapsed since its port mapping table was initialized on
startup or reset for any other reason (see Section 3.7 "Seconds Since startup or reset for any other reason (see Section 3.6 "Seconds Since
Start of Epoch"). Start of Epoch").
Upon receiving the response packet, the client MUST check the source Upon receiving the response packet, the client MUST check the source
IP address, and silently discard the packet if the address is not the IP address, and silently discard the packet if the address is not the
address of the gateway to which the request was sent. address of the gateway to which the request was sent.
If the client receives an "ICMP Port Unreachable" message from the
gateway, then it SHOULD conclude that this gateway does not support
NAT Port Mapping Protocol and MAY log an error message.
3.2.1 Announcing Address Changes 3.2.1 Announcing Address Changes
When the public IP address of the NAT changes, the NAT gateway MUST When the public IP address of the NAT changes, the NAT gateway MUST
send a gratuitous response to the link-local multicast address send a gratuitous response to the link-local multicast address
224.0.0.1, port 5351 with the packet format above to notify clients 224.0.0.1, port 5351 with the packet format above to notify clients
of the new public IP address. To compensate for packet loss, the NAT of the new public IP address. To accommodate packet loss, the
gateway SHOULD multicast 10 address change notifications. The NAT gateway SHOULD multicast 10 address change notifications.
interval between the first two notifications SHOULD be 250ms, and the The interval between the first two notifications SHOULD be 250ms,
interval between each subsequent notification SHOULD double. and the interval between each subsequent notification SHOULD double.
Upon receiving a gratuitous address change announcement packet, Upon receiving a gratuitous address change announcement packet,
the client MUST check the source IP address, and silently discard the client MUST check the source IP address, and silently discard
the packet if the address is not the address of the client's the packet if the address is not the address of the client's
current configured gateway. This is to guard against inadvertent current configured gateway. This is to guard against inadvertent
misconfigurations where there may be more than one NAT gateway misconfigurations where there may be more than one NAT gateway
active on the network. active on the network.
3.3 Creating a Mapping 3.3 Creating a Mapping
To create a mapping, the client sends a UDP packet to port 5351 of To create a mapping, the client sends a UDP packet to port 5351
the gateway's private IP address with the following format: of the gateway's private IP address with the following format:
0 1 2 3 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 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) | | Vers = 0 | OP = x | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Private Port | Requested Public Port | | Private Port | Requested Public Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Port Mapping Lifetime in Seconds | | Requested Port Mapping Lifetime in Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcodes supported: Opcodes supported:
1 - Map UDP 1 - Map UDP
2 - Map TCP 2 - Map TCP
The reserved field MUST be set to zero on transmission and MUST be The Reserved field MUST be set to zero on transmission and MUST
ignored on reception. The RECOMMENDED Port Mapping Lifetime for be ignored on reception.
this protocol is 3600 seconds.
The Private Port is set to the local port on which the client is
listening.
The Requested Public Port SHOULD usually be set to the same value as
the local Private Port, or zero if the client has no preference for
what port is assigned. However, the gateway is not obliged to assign
the port requested, and may choose not to, either for policy reasons
(e.g. port 80 is reserved and clients may not request it) or because
that port has already been assigned to some other client. Because
of this, some product developers have questioned the value of having
the Requested Public Port field at all. The reason is for failure
recovery. Most low-cost home NAT gateways do not record temporary
port mappings in persistent storage, so if the gateway crashes or is
rebooted, all the mappings are lost. A renewal packet is formatted
identically to an initial mapping request packet, except that for
renewals the client sets the Requested Public Port field to the
port the gateway actually assigned, rather than the port the client
originally wanted. When a freshly-rebooted NAT gateway receives a
renewal packet from a client, it appears to the gateway just like
an ordinary initial request for a port mapping, except that in this
case the Requested Public Port is likely to be one that the NAT
gateway *is* willing to allocate (it allocated it to this client
right before the reboot, so it should presumably be willing to
allocate it again).
The RECOMMENDED Port Mapping Lifetime is 3600 seconds.
After sending the port mapping request, the client then waits for the After sending the port mapping request, the client then waits for the
NAT gateway to respond. If after 250ms, the gateway doesn't respond, NAT gateway to respond. If after 250ms, the gateway doesn't respond,
the client SHOULD re-issue its request. The client SHOULD repeat the client SHOULD re-issue its request as described above in Section
this process with the interval between attempts doubling each time. 3.1 "Requests and Responses".
If after two minutes, the client has not received any response, it
SHOULD log an error message and give up.
The NAT gateway responds with the following packet format: The NAT gateway responds with the following packet format:
0 1 2 3 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 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 | | Vers = 0 | OP = 128 + x | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Since Start of Epoch | | Seconds Since Start of Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 7 skipping to change at page 7, line 33
The 'x' in the OP field MUST match what the client requested. Some The 'x' in the OP field MUST match what the client requested. Some
NAT gateways are incapable of creating a UDP port mapping without NAT gateways are incapable of creating a UDP port mapping without
also creating a corresponding TCP port mapping, and vice versa, and also creating a corresponding TCP port mapping, and vice versa, and
these gateways MUST NOT implement NAT Port Mapping Protocol until these gateways MUST NOT implement NAT Port Mapping Protocol until
this deficiency is fixed. A NAT gateway which implements this this deficiency is fixed. A NAT gateway which implements this
protocol MUST be able to create TCP-only and UDP-only port mappings. protocol MUST be able to create TCP-only and UDP-only port mappings.
If a NAT gateway silently creates a pair of mappings for a client If a NAT gateway silently creates a pair of mappings for a client
that only requested one mapping, then it may expose that client to that only requested one mapping, then it may expose that client to
receiving inbound UDP packets or inbound TCP connection requests that receiving inbound UDP packets or inbound TCP connection requests
it did not ask for and does not want. that it did not ask for and does not want.
While a NAT gateway MUST NOT automatically create mappings for TCP While a NAT gateway MUST NOT automatically create mappings for TCP
when the client requests UDP, and vice versa, the NAT gateway SHOULD when the client requests UDP, and vice versa, the NAT gateway MUST
reserve the companion port so the same client can choose to map it in reserve the companion port so the same client can choose to map it
the future. For example, if a client requests to map TCP port 80, as in the future. For example, if a client requests to map TCP port 80,
long as the client maintains the lease for that TCP port mapping, as long as the client maintains the lease for that TCP port mapping,
another client with a different IP address SHOULD NOT be able to another client with a different IP address MUST NOT be able to
successfully acquire the mapping for UDP port 80. successfully acquire the mapping for UDP port 80.
The client normally requests the public port matching the private The client normally requests the public port matching the private
port. If that public port is not available, the NAT gateway MUST port. If that public port is not available, the NAT gateway MUST
return a public port that is available or return an error code if no return a public port that is available or return an error code if
ports are available. If the client has no preference about what no ports are available.
public port is assigned, then it should set the requested public port
to zero.
The source address of the packet MUST be used for the private address The source address of the packet MUST be used for the private address
in the mapping. This protocol is not intended to facilitate one in the mapping. This protocol is not intended to facilitate one
device behind a NAT creating mappings for other devices. If there device behind a NAT creating mappings for other devices. If there
are legacy devices that require inbound mappings, permanent mappings are legacy devices that require inbound mappings, permanent mappings
can be created manually by the administrator, just as they are today. can be created manually by the administrator, just as they are today.
If a mapping already exists for a given private port on a given local If a mapping already exists for a given private port on a given local
client, and that client requests another mapping for the same private client (whether that mapping was created explicitly using NAT-PMP,
port, possibly requesting a different public port, then the mapping implicitly as a result of an outgoing TCP SYN packet, or manually by
request should succeed, returning the already-assigned public port. a human administrator) and that client requests another mapping for
This is necessary to handle the case where a client requests a the same private port (possibly requesting a different public port)
mapping with requested public port X, and is granted a mapping with then the mapping request should succeed, returning the already-
actual public port Y, but the acknowledgement packet gets lost. assigned public port. This is necessary to handle the case where
When the client retransmits its mapping request, it should get back a client requests a mapping with requested public port X, and is
the same positive acknowledgement as was sent the first time. granted a mapping with actual public port Y, but the acknowledgement
packet gets lost. When the client retransmits its mapping request,
it should get back the same positive acknowledgement as was sent (and
lost) the first time.
The NAT gateway SHOULD NOT accept mapping requests destined to the The NAT gateway SHOULD NOT accept mapping requests destined to the
NAT gateway's public IP address or received on its public network NAT gateway's public IP address or received on its public network
interface. Only packets received on the private interface(s) with a interface. Only packets received on the private interface(s) with
destination address matching the private address(es) of the NAT a destination address matching the private address(es) of the NAT
gateway should be allowed. gateway should be allowed.
The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field The NAT gateway MUST fill in the "Seconds Since Start of Epoch" field
with the time elapsed since its port mapping table was initialized on with the time elapsed since its port mapping table was initialized on
startup or reset for any other reason (see Section 3.7 "Seconds Since startup or reset for any other reason (see Section 3.6 "Seconds Since
Start of Epoch"). Start of Epoch").
The Port Mapping Lifetime is an unsigned integer in seconds. The NAT The Port Mapping Lifetime is an unsigned integer in seconds. The NAT
gateway MAY reduce the lifetime from what the client requested. The gateway MAY reduce the lifetime from what the client requested. The
NAT gateway SHOULD NOT offer a lease lifetime greater than that NAT gateway SHOULD NOT offer a lease lifetime greater than that
requested by the client. requested by the client.
Upon receiving the response packet, the client MUST check the source Upon receiving the response packet, the client MUST check the source
IP address, and silently discard the packet if the address is not the IP address, and silently discard the packet if the address is not the
address of the gateway to which the request was sent. address of the gateway to which the request was sent.
The client SHOULD begin trying to renew the mapping halfway to expiry The client SHOULD begin trying to renew the mapping halfway to expiry
time, like DHCP. The renewal packet should look exactly the same as time, like DHCP. The renewal packet should look exactly the same as
a request packet, except that the client SHOULD set the requested a request packet, except that the client SHOULD set the requested
public port to what the router previously mapped. If the router public port to what the NAT gateway previously mapped, not what the
crashes or is rebooted, this helps the router recover its mapping client originally requested. As described above, this enables the
state. gateway to automatically recover its mapping state after a crash or
reboot.
3.4 Destroying a Mapping 3.4 Destroying a Mapping
A mapping may be destroyed in a variety of ways. If a client fails A mapping may be destroyed in a variety of ways. If a client fails
to renew a mapping, then when its lifetime expires the mapping MUST to renew a mapping, then when its lifetime expires the mapping MUST
be automatically deleted. In the common case where the gateway be automatically deleted. In the common case where the gateway
device is a combined DHCP server and NAT gateway, when a client's device is a combined DHCP server and NAT gateway, when a client's
DHCP address lease expires, the gateway device MAY automatically DHCP address lease expires, the gateway device MAY automatically
delete any mappings belonging to that client. Otherwise a new client delete any mappings belonging to that client. Otherwise a new client
being assigned the same IP address could receive unexpected inbound being assigned the same IP address could receive unexpected inbound
skipping to change at page 9, line 13 skipping to change at page 9, line 41
gateway MUST respond with a 'Not Authorized' error, result code 2. gateway MUST respond with a 'Not Authorized' error, result code 2.
When a mapping is destroyed as a result of its lifetime expiring or When a mapping is destroyed as a result of its lifetime expiring or
for any other reason, if the NAT gateway's internal state indicates for any other reason, if the NAT gateway's internal state indicates
that there are still active TCP connections traversing that now- that there are still active TCP connections traversing that now-
defunct mapping, then the NAT gateway SHOULD send appropriately- defunct mapping, then the NAT gateway SHOULD send appropriately-
constructed TCP RST (reset) packets both to the local client and to constructed TCP RST (reset) packets both to the local client and to
the remote peer on the Internet to terminate that TCP connection. the remote peer on the Internet to terminate that TCP connection.
A client can request the explicit deletion of all its UDP or TCP A client can request the explicit deletion of all its UDP or TCP
mappings by sending the same deletion request to the NAT gateway with mappings by sending the same deletion request to the NAT gateway
public port, private port, and lifetime set to 0. A client MAY with public port, private port, and lifetime set to 0. A client MAY
choose to do this when it first acquires a new IP address in order to choose to do this when it first acquires a new IP address in order to
protect itself from port mappings that were performed by a previous protect itself from port mappings that were performed by a previous
owner of the IP address. After receiving such a deletion request, owner of the IP address. After receiving such a deletion request,
the gateway MUST delete all its UDP or TCP port mappings (depending the gateway MUST delete all its UDP or TCP port mappings (depending
on the opcode). The gateway responds to such a deletion request with on the opcode). The gateway responds to such a deletion request with
a response as described above, with the private port set to zero. If a response as described above, with the private port set to zero. If
the gateway is unable to delete a port mapping, for example, because the gateway is unable to delete a port mapping, for example, because
the mapping was manually configured by the administrator, the gateway the mapping was manually configured by the administrator, the gateway
MUST still delete as many port mappings as possible, but respond with MUST still delete as many port mappings as possible, but respond with
a non-zero result code. The exact result code to return depends on a non-zero result code. The exact result code to return depends on
skipping to change at page 10, line 9 skipping to change at page 10, line 36
operation that failed. For example, a client may request a mapping operation that failed. For example, a client may request a mapping
but that mapping may fail due to resource exhaustion. The server but that mapping may fail due to resource exhaustion. The server
SHOULD respond with the result code to indicate resource exhaustion SHOULD respond with the result code to indicate resource exhaustion
(4) followed by the requested port mapping so the client may identify (4) followed by the requested port mapping so the client may identify
which operation failed. which operation failed.
Clients MUST be able to properly handle result codes not defined in Clients MUST be able to properly handle result codes not defined in
this document. Undefined results codes MUST be treated as fatal this document. Undefined results codes MUST be treated as fatal
errors of the request. errors of the request.
3.6 Recreating Mappings On Reboot 3.6 Seconds Since Start of Epoch
The NAT gateway MAY store mappings in persistent storage so when it
is powered off or rebooted, it remembers the port mapping state of
the network. However, maintaining this state is not necessary. When
the NAT gateway powers on or clears its port mapping state as the
result of a configuration change, it MUST reset the epoch time and
re-announce its IP address as described in Section 3.2.1 "Announcing
Address Changes". This will signal to clients on the network that
they need to redo their mappings.
When a client renews its port mappings as the result of receiving
such a packet, it MUST first delay by a random amount of time
selected with uniform random distribution in the range 0 to 5
seconds, and then send its first port mapping request. After that
request is acknowledged by the gateway, it may then send its second
request, and so on, as rapidly as the gateway allows. The requests
SHOULD be issued serially, one at a time; the client SHOULD NOT
issue multiple requests simultaneously in parallel.
3.7 Seconds Since Start of Epoch
Every packet sent by the NAT gateway includes a "Seconds since start Every packet sent by the NAT gateway includes a "Seconds since start
of epoch" field (SSSOE). If the NAT gateway resets or loses the of epoch" field (SSSOE). If the NAT gateway resets or loses the
state of its port mapping table, due to reboot, power failure, or any state of its port mapping table, due to reboot, power failure, or any
other reason, it MUST reset its epoch time and begin counting SSSOE other reason, it MUST reset its epoch time and begin counting SSSOE
from 0 again. Whenever a client receives any packet from the NAT from 0 again. Whenever a client receives any packet from the NAT
gateway, either gratuitously or in response to a client request, the gateway, either gratuitously or in response to a client request, the
client computes its own conservative estimate of the expected SSSOE client computes its own conservative estimate of the expected SSSOE
value by taking the SSSOE value in the last packet it received from value by taking the SSSOE value in the last packet it received from
the gateway and adding 7/8 (87.5%) of the time elapsed since that the gateway and adding 7/8 (87.5%) of the time elapsed since that
packet was received. If the SSSOE in the newly received packet is packet was received. If the SSSOE in the newly received packet is
less than the client's conservative estimate, then the client less than the client's conservative estimate by more than one second,
concludes that the NAT gateway has undergone a reboot or other loss then the client concludes that the NAT gateway has undergone a reboot
of port mapping state, and the client MUST immediately renew all its or other loss of port mapping state, and the client MUST immediately
active port mapping leases as described in Section 3.6 "Recreating renew all its active port mapping leases as described in Section 3.7
Mappings On Reboot". "Recreating Mappings On NAT Gateway Reboot".
3.7 Recreating Mappings On NAT Gateway Reboot
The NAT gateway MAY store mappings in persistent storage so when it
is powered off or rebooted, it remembers the port mapping state of
the network.
However, maintaining this state is not essential for correct
operation. When the NAT gateway powers on or clears its port mapping
state as the result of a configuration change, it MUST reset the
epoch time and re-announce its IP address as described in Section
3.2.1 "Announcing Address Changes". Reception of this packet where
time has apparently gone backwards serves as a hint to clients
on the network that they SHOULD immediately send renewal packets
(to immediately recreate their mappings) instead of waiting until
the originally scheduled time for those renewals. Clients who miss
receiving those gateway announcement packets for any reason will
still renew their mappings at the originally scheduled time and cause
their mappings to be recreated; it will just take a little longer for
these clients.
A mapping renewal packet is formatted identically to an original
mapping request; from the point of view of the client it is a
renewal of an existing mapping, but from the point of view of the
freshly-rebooted NAT gateway it appears as a new mapping request.
This self-healing property of the protocol is very important.
The remarkable reliability of the Internet as a whole derives
in large part from the fact that important state is held in the
endpoints, not in the network itself [ETEAISD]. Power-cycling an
Ethernet switch results only in a brief interruption in the flow
of packets; established TCP connections through that switch are not
broken, merely delayed for a few seconds. Indeed, an old Ethernet
switch can even be replaced with a new one, and as long as the cables
are transferred over reasonably quickly, after the upgrade all the
TCP connections that were previously going though the old switch will
be unbroken and now going through the new one. The same is true of
IP routers, wireless base stations, etc. The one exception is NAT
gateways. Because the port mapping state is required for the NAT
gateway to know where to forward inbound packets, loss of that state
breaks connectivity through the NAT gateway. By allowing clients to
detect when this loss of NAT gateway state has occurred, and recreate
it on demand, we turn hard state in the network into soft state, and
allow it to be recovered automatically when needed.
Without this automatic recreation of soft state in the NAT gateway,
reliable long-term networking would not be achieved. As mentioned
above, the reliability of the Internet does not come from trying
to build a perfect network in which errors never happen, but from
accepting that in any sufficiently large system there will always be
some component somewhere that's failing, and designing mechanisms
that can handle those failures and recover. To illustrate this point
with an example, consider the following scenario: Imagine a network
security camera that has a web interface and accepts incoming
connections from web browser clients. Imagine this network security
camera uses NAT-PMP or a similar protocol to set up an inbound
port mapping in the NAT gateway so that it can receive incoming
connections from clients the other side of the NAT gateway.
Now, this camera may well operate for weeks, months, or even years.
During that time it's possible that the NAT gateway could experience
a power failure or be rebooted. The user could upgrade the NAT
gateway's firmware, or even replace the entire NAT gateway device
with a newer model. The general point is that if the camera operates
for a long enough period of time, some kind of disruption to the NAT
gateway becomes inevitable. The question is not whether the NAT
gateway will lose its port mappings, but when, and how often.
If the network camera and devices like it on the network can detect
when the NAT gateway has lost its port mappings, and recreate them
automatically, then these disruptions are self-correcting and
invisible to the end user. If, on the other hand, the disruptions are
not self-correcting, and after a NAT gateway reboot the user has to
manually reset or reboot all the other devices on the network too,
then these disruptions are *very* visible to the end user. This
aspect of the design is what makes the difference between a protocol
that keeps on working indefinitely over a time scale of months or
years, and a protocol that works in brief testing, but in the real
world is continually failing and requiring manual intervention to get
it going again.
When a client renews its port mappings as the result of receiving
a packet where the "Seconds since start of epoch" field (SSSOE)
indicates that a reboot or similar loss of state has occurred,
the client MUST first delay by a random amount of time selected
with uniform random distribution in the range 0 to 5 seconds, and
then send its first port mapping request. After that request is
acknowledged by the gateway, the client may then send its second
request, and so on, as rapidly as the gateway allows. The requests
SHOULD be issued serially, one at a time; the client SHOULD NOT issue
multiple requests simultaneously in parallel.
The discussion in this section focusses on recreating inbound port
mappings after loss of NAT gateway state, because that is the more
serious problem. Losing port mappings for outgoing connections
destroys those currently active connections, but does not prevent
clients from establishing new outgoing connections. In contrast,
losing inbound port mappings not only destroys all existing inbound
connections, but also prevents the reception of any new inbound
connections until the port mapping is recreated. Accordingly,
we consider recovery of inbound port mappings the more important
priority. However, clients that want outgoing connections to survive
a NAT gateway reboot can also achieve that using NAT-PMP. After
initiating an outbound TCP connection (which will cause the NAT
gateway to establish an implicit port mapping) the client should send
the NAT gateway a port mapping request for the source port of its TCP
connection, which will cause the NAT gateway to send a response
giving the public port it allocated for that mapping. The client can
then store this information, and use later to recreate the mapping
if it determines that the NAT gateway has lost its mapping state.
3.8 NAT Gateways with NAT Function Disabled
Note that *only* devices currently acting in the role of NAT gateway
should participate in NAT-PMP protocol exchanges with clients.
A network device that is capable of NAT (and NAT-PMP), but is
currently configured not to perform that function, (e.g. it is
acting as a traditional IP router, forwarding packets without
modifying them), MUST NOT respond to NAT-PMP requests from clients,
or send spontaneous NAT-PMP address-change announcements.
In particular, a network device not currently acting in the role of
NAT gateway should not even respond to NAT-PMP requests by returning
an error code such as "2 - Not Authorized/Refused", since to do so
is misleading to clients -- it suggests that NAT port mapping is
necessary on this network for the client to successfully receive
inbound connections, but is not available because the administrator
has chosen to disable that functionality.
Clients should also be careful to avoid making unfounded assumptions,
such as the assumption that if the client has an IPv4 address in
one of the RFC 1918 private IP address ranges then that means
NAT necessarily must be in use. Net 10/8 has enough addresses
to build a private network with millions of hosts and thousands
of interconnected subnets, all without any use of NAT. Many
organizations have built such private networks that benefit from
using standard TCP/IP technology, but by choice do not connect
to the public Internet. The purpose of NAT-PMP is to mitigate some
of the damage caused by NAT. It would be an ironic and unwanted
side-effect of this protocol if it were to lead well-meaning but
misguided developers to create products that refuse to work on a
private network *unless* they can find a NAT gateway to talk to.
Consequently, a client finding that NAT-PMP is not available on its
network should not give up, but should proceed on the assumption
that the network may be a traditional routed IP network, with no
address translation being used. This assumption may not always be
true, but it is better than the alternative of falsely assuming
the worst and not even trying to use normal (non-NAT) IP networking.
If a network device not currently acting in the role of NAT gateway
receives UDP packets addressed to port 5351, it SHOULD respond
immediately with an "ICMP Port Unreachable" message to tell the
client that it needn't continue with timeouts and retransmissions,
and it should assume that NAT-PMP is not available and not needed
on this network.
4. UNSAF Considerations 4. UNSAF Considerations
The document "IAB Considerations for UNSAF Across NAT" [RFC 3424] The document "IAB Considerations for UNSAF Across NAT" [RFC 3424]
covers a number of issues when working with NATs. RFC 3424 outlines covers a number of issues when working with NATs. RFC 3424 outlines
some requirements for any document that attempts to work around some requirements for any document that attempts to work around
problems associated with NATs. This section addresses those problems associated with NATs. This section addresses those
requirements. requirements.
4.1 Scope 4.1 Scope
skipping to change at page 12, line 18 skipping to change at page 15, line 18
have chosen to allow each customer a reasonable number of addresses, have chosen to allow each customer a reasonable number of addresses,
enough for each customer device to have its own NAT address directly enough for each customer device to have its own NAT address directly
from the ISP. If instead this ISP chooses to allow each customer from the ISP. If instead this ISP chooses to allow each customer
just one and only one NAT address, forcing said customer to run just one and only one NAT address, forcing said customer to run
nested NAT in order to use more than one device, it seems unlikely nested NAT in order to use more than one device, it seems unlikely
that such an ISP would be so obliging as to provide a NAT service that such an ISP would be so obliging as to provide a NAT service
that supports NAT Port Mapping Protocol. Supposing that such an ISP that supports NAT Port Mapping Protocol. Supposing that such an ISP
did wish to offer its customers NAT service with NAT-PMP so as to did wish to offer its customers NAT service with NAT-PMP so as to
give them the ability to receive inbound connections, this ISP could give them the ability to receive inbound connections, this ISP could
easily choose to allow each client to request a reasonable number of easily choose to allow each client to request a reasonable number of
DHCP addresses from that gateway. Remember that Net 10 [RFC 1918] DHCP addresses from that gateway. Remember that Net 10/8 [RFC 1918]
allows for over 16 million addresses, so NAT addresses are not in any allows for over 16 million addresses, so NAT addresses are not in any
way in short supply. A single NAT gateway with 16 million available way in short supply. A single NAT gateway with 16 million available
addresses is likely to run out of packet forwarding capacity before addresses is likely to run out of packet forwarding capacity before
it runs out of private addresses to hand out. In this way the ISP it runs out of private addresses to hand out. In this way the ISP
could offer single-level NAT with NAT-PMP, obviating the need to could offer single-level NAT with NAT-PMP, obviating the need to
support nested NAT-PMP. In addition, an ISP that is motivated to support nested NAT-PMP. In addition, an ISP that is motivated to
provide their customers with unhindered access to the Internet by provide their customers with unhindered access to the Internet by
allowing incoming as well as outgoing connections has better ways to allowing incoming as well as outgoing connections has better ways
offer this service. Such an ISP could offer its customers real to offer this service. Such an ISP could offer its customers real
public IP addresses instead of NAT addresses, or could even choose to public IP addresses instead of NAT addresses, or could even choose
offer its customers full IPv6 connectivity, where no mapping or to offer its customers full IPv6 connectivity, where no mapping or
translation is required at all. translation is required at all.
4.3.2 NATs with Multiple Public IP Addresses 4.3.2 NATs with Multiple Public IP Addresses
If a NAT maps private addresses to multiple public addresses, If a NAT maps private addresses to multiple public addresses,
then it SHOULD pick one of those addresses as the one it will then it SHOULD pick one of those addresses as the one it will
support for inbound connections, and for the purposes of this support for inbound connections, and for the purposes of this
protocol it SHOULD act as if that address were its only address. protocol it SHOULD act as if that address were its only address.
4.3.3 NATs and Routed Private Networks 4.3.3 NATs and Routed Private Networks
In some cases, a large network may be subnetted. Some sites may In some cases, a large network may be subnetted. Some sites
install a NAT gateway and subnet the private network. Such may install a NAT gateway and subnet the private network.
subnetting breaks this protocol because the router address is not Such subnetting breaks this protocol because the router address
necessarily the address of the device performing NAT. is not necessarily the address of the device performing NAT.
Addressing this problem is not a high priority. Any site with the Addressing this problem is not a high priority. Any site with the
resources to set up such a configuration should have the resources to resources to set up such a configuration should have the resources to
add manual mappings or attain a range of globally unique addresses. add manual mappings or attain a range of globally unique addresses.
Not all NATs will support this protocol. In the case where a client 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 is run behind a NAT that does not support this protocol, the software
relying on the functionality of this protocol may be unusable. relying on the functionality of this protocol may be unusable.
4.3.4 Communication Between Hosts Behind the Same NAT 4.3.4 Communication Between Hosts Behind the Same NAT
 End of changes. 27 change blocks. 
102 lines changed or deleted 271 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/