http://www.watersprings.org/pub/id/draft-takeda-symmetric-nat-traversal-00.txt
Internet Engineering Task Force MIDCOM WG
Internet Draft Y.Takeda
draft-takeda-symmetric-nat-traversal-00.txt Panasonic Communications
Category: Informational Research Laboratory
Symmetric NAT Traversal using STUN
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026 except that the right to produce derivative
works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
It is generally known that the binding acquisition for symmetric NATs
with STUN (Simple Traversal of UDP through NATs) protocol will not
yield a usable address for traversing symmetric NAT. The use of
symmetric RTP allows you to accompolish symmetric NAT traversal only
in situations where the other end is open to the Internet, or has a
full-cone or a restricted-cone NAT. This document proposes an
analytical method for symmetric NATs to obtain more detailed
characteristics of the symmetric NAT using STUN, and describes how we
can establish a peer-to-peer UDP connection even in situations where
NATs (including symmetric NATs) are present at both ends.
Takeda [Page 1]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
1 Introduction
STUN is a useful tool to discover the presence and characteristics of
Network Address Translators (NATs). (It does not support 'traversal'
by itself.) It is generally known that the binding acquisition for
symmetric NATs, with STUN, will not yield a usable address, and in
cases that the other end also has a port restricted-cone NAT or
symmetric NAT, there is no possible way to traverse these NATs.
We have discovered in our NAT characteristics research, that the
number of symmetric NATs deployed in the market is significant even
in the residential market. This is a significant issue, especially
for service providers or manufacturers who are seriously looking for
a solution to the actual NAT issues they have.
TURN (Traversal Using Relay NAT)[2] has been proposed to complement
the limitation of STUN, however, this type of solution requires a
relay server somewhere on the public network, which is an additional
cost for service providers. It is important that service providers
reduce the amount of server deployments as much as possible.
This document proposes an analytical method for symmetric NATs to
obtain more detailed characteristics of symmetric NATs using STUN,
and describes how we can establish a peer-to-peer UDP connection even
in situations where the NATs (including symmetric NATs) are present
at both ends. The operation is based upon a prediction of a set of IP
address and port that a symmetric NAT will allocate. However, the
discovery processes proposed in this document, using STUN, produce a
fairly good success rate of symmetric NAT traversal. As a result, it
will significantly reduce the requirement for relay servers.
This document does not provide any specific protocol, nor a proposal
for any modifications to current STUN protocol. In order to
incorporate the method described in this document into existing
protocols (e.g. SDP), those protocols will need to be modified. It
is expected that this method be appropriately examined in this public
community to yield improvements and as motivation for applying it to
both old and new protocols.
2 Terminology
NAT - Network Address Translation
RTP - Real-time Transfer Protocol
SDP - Session Description Protocol
Takeda [Page 2]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
STUN - Simple Traversal of UDP through NATs
TURN - Traversal Using Relay NATs
UDP - User Datagram Protocol
3 Network Configuration
The assumption in this document is based upon what is shown in Figure
3.1, in that there are one or more NATs at both endpoints(EP-a and
EP-b) that wish to communicate to each other directly through the
NATs. In order to get information about the NATs, each endpoint uses
a STUN server located on the public network.
STUN Server
+-----+
NAT NAT | | NAT NAT
+-+ +-+ +--+--+ +-+ +-+
+----+ | | | | | | | | | +----+
|EP-a|---+ +...+ +---((Public Network))---+ +...+ +---|EP-b|
+----+ | | | | | | | | +----+
+-+ +-+ +-+ +-+
Figure 3.1 Network Configuration
4 NAT Behavior Analogy
An analogy is provided here to aid in the explanation of how the
various NATs operate. It is assumed that readers of this document are
familiar with STUN protocol[1] and have a good understanding of NAT
behaviors.
The analogy is presented in terms of a doorman to a building
(corresponding to a private network) in which a tenant (an endpoint
device) is present. A NAT acts just like a wall of the building.
Until the tenant sends a packet to the outside, there are no doors on
the wall of the building. When the tenant in the building sends a
packet, a door on the wall will be created with a doorman. The NAT
behavior can be characterized in different ways depending on the
doorman's role and the rules that created the door.
Full-cone NAT:
A door will be created when a tenant(endpoint) in a building
Takeda [Page 3]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
sends a packet for the first time. In the case of a full-cone
NAT, the doorman standing at the door checks if each packet
trying to come in is visiting the tenant who created this door.
The doorman, however, does not check where each packet
originates.
Restricted-cone NAT:
A door will be created when a tenant(endpoint) in a building
sends an invitation letter (a packet) for the first time to
another building. In this case, the doorman will check if each
person (packet) trying to come in is visiting the tenant who
created this door. The doorman also checks if visitors came from
the building that received the invitation letter from the
tenant.
Port restricted-cone NAT:
A door will be created when a tenant(endpoint) in a building
sends an invitation letter (a packet) for the first time to a
tenant in another building. The doorman will check if each
person trying to enter is visiting the tenant who created the
door. The doorman also checks if they have received the
invitation letter from the tenant.
Symmetric NAT:
A door will be created every time when a tenant(endpoint) in a
building sends an invitation letter (a packet) to a new tenant
in another building. The doorman will check if each one trying
to come in is visiting the tenant who created the door. The
doorman also checks if they have received the invitation letter
sent from him through this door.
What makes NAT traversal difficult with symmetric NAT is the
door creation rule. In other (non-symmetric) cases, the same
door will be used whenever the same tenant in a building sends
an invitation packet to a different destination. In symmetric
NAT , a new door will be always created every time the tenant in
the building sends an invitation packet. Therefore, when you
want to talk to Mr.A and Mr.B at the same time, for example, the
door to let Mr.A enter is always different from the one to let
Mr.B enter. With STUN, the tenant sends an invitation packet to
the STUN server (binding request) and the STUN server sends back
a reply with the location of the door (MAPPED-ADDRESS) used to
send the invitation, so that the tenant will know which door on
the NAT can be used for other parties to enter. However, if the
NAT is symmetric, the door obtained from the STUN server is not
Takeda [Page 4]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
the same as the door that will be used for other parties to
enter.
In this analogy, a 'tenant' is used to represent a local UDP port.
It should be noted that several tenants comprise a 'company'. The IP
address represents a company in the 'building'. To recap, each
building (LAN behind a NAT) has multiple companies (IP addresses)
made up of many tentants (UDP ports). The trick to traverse NAT with
UDP is to utilize the 'invitation letter (packet)". This will create
a door for visitors outside the building to come in. The invitation
packet is not necessarily a 'special' invitation packet. The first
part of data transmission works as an invitation because it creates a
door and a doorman as a result. STUN protocol provides us with a way
to ascertain the doorman's role and the door creation rule.
5 NAT Combination Classification & Current Approach
The following chart shows combinations of NATs at each endpoint with
the current NAT type definitions in STUN. The combinations are
classified into 4 groups: Class I, II, III and IV.
+----------+-----+-----+-----+-----+-----+
|\ EP-R| | | | | |
| -------- |Open | F | P | PR | SYM |
|EP-S \| | | | | |
|----------+-----+-----+-----+-----+-----+
| Open | | | |
|----------+ | | |
| F | | |(III)|
|----------+( I )| ( II ) | |
| P | | | |
|----------+ | +-----+
| PR | | | |
|----------+ | +-----+ |
| SYM | | | (IV) |
+----------+-----------------+-----------+
Note:
EP-S: Sending endpoint.
EP-R: Receiving endpoint.
(In full-duplex, both EP-a and EP-b in Figure 3.1
will have both EP-S and EP-R)
Open: Open to public network (no NAT)
F : Full-cone NAT
R : Restricted-cone NAT
PR : Port restricted-cone NAT
Takeda [Page 5]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
SYM : Symmetric NAT
Figure 5.1 NAT Combination Classification
Class I is a case in which the receiver does not have a NAT. There is
no actual NAT issue here because receiver side has no NAT and has a
routable IP address to receive packets.
Class II is a case in which the receiver has a non-symmetric NAT and
the sender has no NAT or any type of NATs except the case in which
the receiver has a port restricted symmetric NAT and sender has a
symmetric NAT. In order to traverse the NAT in this case, the
receiver sends an invitation packet to the sender so that the doorman
will not block any packets sent from the receiver of the invitation
packet.
Class III involves a symmetric NAT at the receiver. There is a full-
cone or restricted-cone NAT at the sender side. The problem in this
case is that STUN is not able to provide a valid MAPPED-ADDRESS of
the symmetric NAT for EP-S to send packet. EP-S can send an
invitation packet to the MAPPED-ADDRESS on EP-R side NAT. This will
cause an existing allocated port on EP-S side NAT to accept incoming
packets sent from the MAPPED-ADDRESS on the EP-R side NAT. EP-R will
also send an invitation packet to EP-S and the EP-S can record the
source IP address and port number of the received packet to send
packets back to the recorded address/port. This source address
recording technique is known as "symmetric RTP"[3],[4].
Class IV is the case that this document addresses. The problem here
is that STUN is not able to provide a valid MAPPED-ADDRESS for the
symmetric NAT. Therefore, the other endpoint cannot send an
invitation packet to the symmetric NAT. As a result, the symmetric
RTP solution is not applicable here either. A key solution to this
class IV traversal is to do further analysis on the symmetric NAT and
make the invalid MAPPED-ADDRESS useful. The details are described in
the following sections.
6 More About Symmetric NAT Behavior
6.1 Port Allocation Behavior
A symmetric NAT allocates different mapping (MAPPED-ADDRESS) when a
new request is sent to a different destination, although it is sent
from the same internal IP address and port. In the non-symmetric
case, the same MAPPED-ADDRESS is always used. The following is a
Takeda [Page 6]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
typical example of the port assignment behavior of the symmetric NAT.
In this example, 4 packets (TRY-1 thru -4) are sent to a different
destination from the same internal IP address and port. TRY-1 and 2
send a packet to different port numbers of the same IP address. TRY-3
and -4 do so but to a different IP address from the one in TRY-1 and
-2.
[TRY] [FROM] [TO] [MAPPED-ADDRESS]
1 192.168.1.2:4136 65.12.66.10:3478 67.105.12.10:49152
2 192.168.1.2:4136 65.12.66.10:3479 67.105.12.10:49153 (49152+1)
3 192.168.1.2:4136 65.12.66.11:3478 67.105.12.10:49154 (49153+1)
4 192.168.1.2:4136 65.12.66.11:3479 67.105.12.10:49155 (49154+1)
The symmetric NAT allocates a new MAPPED-ADDRESS, however the
increment size of its port number, called 'delta p', is, in most
cases constant. In the example above, the delta p value is '+1'. It
is known that delta p takes on another value other than '+1', as in
the example below.
[TRY] [FROM] [TO] [MAPPED-ADDRESS]
1 192.168.1.2:4136 65.12.66.10:3478 67.105.12.10:49152
2 192.168.1.2:4136 65.12.66.10:3479 67.105.12.10:49154 (49152+2)
3 192.168.1.2:4136 65.12.66.11:3478 67.105.12.10:49156 (49154+2)
4 192.168.1.2:4136 65.12.66.11:3479 67.105.12.10:49158 (49156+2)
With regard to port allocation behavior, since the symmetric NAT
shown above allocates a new MAPPED-ADDRESS every time a packet is
sent to a different IP address or port, this allocation behavior is
called 'port sensitive' allocation.
It is also known that there is another type of port allocation
behavior as follows.
[TRY] [FROM] [TO] [MAPPED-ADDRESS]
1 192.168.1.2:4136 65.12.66.10:3478 67.105.12.10:49152
2 192.168.1.2:4136 65.12.66.10:3479 67.105.12.10:49152
3 192.168.1.2:4136 65.12.66.11:3478 67.105.12.10:49153 (49152+1)
4 192.168.1.2:4136 65.12.66.11:3479 67.105.12.10:49153
5 192.168.1.2:4136 65.12.66.12:3478 67.105.12.10:49154 (49153+1)
6 192.168.1.2:4136 65.12.66.12:3479 67.105.12.10:49154
7 192.168.1.2:4136 65.12.66.13:3478 67.105.12.10:49155 (49154+1)
8 192.168.1.2:4136 65.12.66.13:3479 67.105.12.10:49155
This symmetric NAT behaves, in terms of port allocation rule, like a
cone (non-symmetric) NAT when packets are sent to different ports of
the same IP address. But when the packets are sent to the different
IP addresses for the first time, it will assign a new MAPPED-ADDRESS.
Takeda [Page 7]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
This port allocation rule is called 'address sensitive' allocation.
Even in this case the port increment size, delta p, is likely to be
constant.
The consistency of delta p is very important in order to traverse
symmetric NAT. If an IP device behind a symmetric NAT knows the
value of delta p and its consistency, the IP device can predict the
next port number to be assigned by the symmetric NAT from the MAPPED-
ADDRESS. The prediction, however, can fail.
One of the scenarios for prediction failure would be that another PC
behind the same symmetric NAT created a new binding during the
prediction process. Specifically, if there are multiple network
applications running behind the same symmetric NAT, ap1 and ap2 shown
in Figure 6.1 for example, ap1 first obtains a MAPPED-ADDRESS from
STUN server (t0). Right after, ap2 starts talking to a remote host
with UDP that causes another binding creation on the NAT (t1). The
ap1 makes a prediction from the obtained MAPPED-ADDRESS but the
predicted port number has just been taken by ap2. Eventually, ap1
sends a packet to a remote host (at t2) but the allocated port by the
NAT for this transmission is not the one that the ap1 has predicted.
[ap1] [ap2] [NAT] [STUN Server] [Host] [Host]
| | | | | |
| | t0| Binding Request | | |
+-------------+------------------>| | |
| | | | | |
| | | MAPPED-ADDRESS | | |
|<------------+-------------------+ | |
| | | | | |
| | t1| Packet sent | | |
| +------+------------------------------------->|
| | | | | |
| | t2| Packet sent | | |
+-------------+------------------------------>| |
| | | | | |
Figure 6.1 Prediction Failure Case A
The critical time period for the correct prediction is between t0 and
t2. Prediction failure rate is determined by binding occurrence
probability by another application behind the same NAT during the
time period. Success rate can be maximized by minimizing the length
of the time period.
Typically, a symmetric NAT allocates a port for a new binding from a
specific range of ports. (e.g. 0xC000 - 0xCFFF) In most cases, the
allocation starts from the beginning of the port range and when it
Takeda [Page 8]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
hits the bottom of the range, it will start over from the beginning.
This port assignment method of NAT is called "incremental
allocation". With the incremental allocation, there usually is a
table that keeps the status of each port in the NAT. The table has a
status flag that shows whether or not the associated port is in use.
The symmetric NAT, when a new binding is being created, looks for the
next available port number by looking at the status flag. If it is in
use, it will skip the port and look at the next port. If the
prediction is made right before the skip occurs, the prediction will
fail. This may happen if there are a number of IP devices connected
behind the same NAT and noticeable amounts of UDP transactions are
being made.
In contrast to the incremental allocation, there is another
allocation method, called "queued resource allocation". In this
method, a predetermined range of port numbers are stored in a queue
(FIFO) in an orderly fashion at the initial phase. When a binding
occurs, a port number will be read from the queue to be allocated for
the binding. After the binding is released, the port number will be
returned back into the queue. Since the length of the binding life-
time varies, the order of the returned port numbers will not be
continuous. That means, the order of the port numbers in the queue
will be shuffled gradually and start losing continuity, which makes
port prediction very difficult.
Here is a summary for possible reasons for port prediction failure:
(a) Another binding occurrence between t0 and t2.
(b) Hit the bottom of the port range. (incremental allocation)
(c) High UDP usage in the local network.
(d) Random port allocation (typically with queued resource allocation)
In order to prevent port prediction failure, the following solutions
can be taken:
- Minimize the time length between t0 and t1. - for (a)
- Implement a retry process. - for (a), (b), (c)
- Multiple port prediction. (see 8.4) - for (a), (b), (c)
There is no practical solution for (d) at this moment. There might be
a way to recover the port number continuity in the queue by
manipulating allocation and release timings of the bindings of the
NAT, however, it might have other disruptive factors caused by the
non-norm NAT world.
6.2 Incoming Packet Filtering
Takeda [Page 9]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
Another factor that characterizes symmetric NAT behavior is the
incoming packet filter type. Once a MAPPED-ADDRESS is allocated on
the symmetric NAT for an internal device, the allocated port will
accept incoming packets sent from an IP address and port to where the
device has previously sent packets. There can be a symmetric NAT that
accepts incoming packets sent from other external endpoints, just
like a full-cone NAT or a restricted-cone NAT, in terms of incoming
packet filtering.
The current STUN discovery process assumes that a symmetric NAT does
not route incoming packets sent from other IP addresses and/or ports
other than one to which an internal device previously sent a packet.
In fact, with the STUN discovery process, a symmetric NAT that
accepts packets from other IP addresses will result in a full-cone
NAT.
The sensitivity, in terms of the incoming packet filter, to a source
IP address and port number of the incoming packet needs to be
evaluated as well as the port allocation rule. If the incoming
packets are examined by the sender's IP address and port number, this
is called 'port sensitive' filtering. If the packets are examined by
the sender's IP address only, it is called, 'address sensitive'
filtering.
6.3 NAT Characteristics Classification
As discussed in section 6.1 and 6.2, symmetric behavior can be
characterized with two parameters as follows:
(1) Port Allocation Rule (door creation rule)
(2) Incoming Packet Filter (doorman's role)
These parameters can be applied to non-symmetric NATs, as well. The
following chart shows all the possible NAT characteristics evaluated
with the two parameters mentioned above.
Takeda [Page 10]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
Table 6.3.1 NAT Characteristics Classification
+----------------------+-----------------------------------+
| | Incoming Packet Filter |
| |-----------------------------------|
| | No Filter | AS Filter | PS Filter |
+----------+-----------+-----------+-----------+-----------+
| | Cone | Full-cone |Restricted-|Port restr-|
| Port | | |cone |icted-cone |
|Allocation|-----------+-----------+-----------+-----------|
| Rule | AS | Symmetric | Symmetric | Symmetric |
| | Symmetric | (a) | (b) | (c) |
| |-----------+-----------+-----------+-----------|
| | PS | Symmetric | Symmetric | Symmetric |
| | Symmetric | (d) | (e) | (f) |
+----------------------+-----------------------------------+
(NOTE) AS: Address Sensitive, PS: Port Sensitive
All the non-symmetric NATs are categorized as 'cone' NAT. There are
three types of cone NATs corresponding to the three incoming packet
filter types.
The other six NAT types are members of a symmetric NAT defined in
STUN except Symmetric (a) and symmetric (d). These symmetric types
are classified as a full-cone NAT. It is assumed in the current STUN
process that if a packet is received in Test II, it determines that
the NAT is full-cone without evaluating its port allocation rule. The
details of this issue are discussed in section 6.5.
In order to detect the six types of symmetric NATs shown in this
table, current STUN message definition and its server can be used as
is. This symmetric NAT discovery process is described in section 7.
6.4 Exceptional Behavior
A symmetric NAT has exceptional behavior on port allocation that
might help NAT traversal. The symmetric NAT allocates a port as well
as typical symmetric NAT behaviors but this symmetric NAT allocates
the same port number as its local port number.
[TRY] [FROM] [TO] [MAPPED-ADDRESS]
1 192.168.1.2:4136 65.12.66.10:3478 67.105.12.10:4136
2 192.168.1.2:4136 65.12.66.10:3479 67.105.12.10:49152
3 192.168.1.2:4136 65.12.66.11:3478 67.105.12.10:49153
4 192.168.1.2:4136 65.12.66.11:3479 67.105.12.10:49154
5 192.168.1.2:4137 65.12.66.10:3478 67.105.12.10:4137
6 192.168.1.2:4137 65.12.66.10:3479 67.105.12.10:49155
7 192.168.1.2:4137 65.12.66.11:3478 67.105.12.10:49156
Takeda [Page 11]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
8 192.168.1.2:4137 65.12.66.11:3479 67.105.12.10:49157
If a device behind this type of NAT knows its behavior, the device
will be able to detect that the port number to be allocated by this
symmetric NAT will have the same port number as the local port bound
in a UDP socket of the device. In this case, once the device detects
the type of NAT, it will not perform the binding request to the STUN
server and use the local port as a global one with a previously
obtained global IP address from the STUN server.
6.5 Symmetric (a) and (d) and Full-cone NAT
Symmetric (a) and (d) are types of symmetric NAT, but they behave
like a full-cone NAT in terms of the incoming packet filtering. STUN
discovery process with these types of NAT results in full-cone, which
is fine but it might have a problem if the device (e.g. EP-a) behind
the NAT needs to send a packet to the other endpoint (EP-b).
After obtaining a MAPPED-ADDRESS, EP-a tells EP-b the MAPPED-ADDRESS
so that EP-b can send packets to EP-a via the MAPPED-ADDRESS. If EP-a
wants to send a packet to EP-b, the packet transmission will cause a
new port allocation on the NAT because the NAT is actually a
symmetric NAT. Then EP-b will receive a packet from the new port. EP-
b believes that it is sending packets to the MAPPED-ADDRESS to talk
to EP-a, but the packet is coming from a different port than the
MAPPED-ADDRESS. This might cause some confusion in EP-b.
7 NAT Characteristics Discovery using STUN
Current STUN message format and test definitions are used as is in
order to detect the NAT types defined in Table 6.3.1.
Test I: The client sends a STUN Binding Request to a server,
without any flags set in the CHANGE-REQUEST attribute, and without
the RESPONSE-ADDRESS attribute. This causes the server to send the
response back to the address and port that the request came from.
Test II: The client sends a Binding Request with both the "change
IP" and "change port" flags from the CHANGE-REQUEST attribute set.
Test III: The client sends a Binding Request with only the "change
port" flag set.
It does not require any modification to STUN server, either. The only
Takeda [Page 12]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
difference is the discovery process flow as described in the
following sections.
7.1 Incoming Packet Filter Type Discovery
The client begins by initiating Test I. If this test yields no
response, the client knows right away that it is not capable of UDP
connectivity. If the test produces a response, the client examines
the MAPPED-ADDRESS attribute. If this address and port are the same
as the local IP address and port of the socket used to send the
request, the client knows that it is not "natted". The client then
executes Test II.
If a response is received during the Test II, the client knows that
it has open access to the Internet (or, at least, its behind a
firewall that behaves like a full-cone NAT, but without the
translation). If no response is received, the client knows its behind
a symmetric UDP firewall.
In the event that the IP address and port of the socket did not match
the MAPPED-ADDRESS attribute in the response to Test I, the client
knows that it is behind a NAT.
Specifically, the process up until this point is considered the NAT
presence discovery process. The following process covers the incoming
packet filter type discovery that is performed only in situations
where the client is behind one or more NATs.
The client performs Test II. If a response is received, the client
knows that the NAT that the client is behind has no port filter. If
no response is received, the client performs Test III. If a response
is received, the client is behind a NAT that has an address sensitive
filter. If no response is received, the NAT has a port sensitive
filter.
Takeda [Page 13]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
+--------+
| Test |
| I |
+--------+
|
|
V
/\ /\
N / \ Y / \ Y +--------+
UDP <-------/resp\--------->/ IP \------------->| Test |
Blocked \ ? / \Same/ | II |
\ / \? / +--------+
\/ \/ |
| N |
| V
V /\
+--------+ Sym. N / \
| Test | UDP <---/resp\
| II | Firewall \ ? /
+--------+ \ /
| \/
V |Y
/\ |
+--------+ N / \ V
| Test |<------- /Resp\ Open
| III | \ ? / Internet
+--------+ \ /
| \/
| |Y
| |
| +--> No Filter
V
/\
/ \ Y
/Resp\-----------------> Address Sensitive Filter
\ ? /
\ /
\/
|N
|
+-------------------> Port Sensitive Filter
Figure 7.1 Incoming Filter Type Discovery Process Flow
7.2 Port Allocation Rule Discovery
The port allocation rule discovery process is performed only in
Takeda [Page 14]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
situations where the device is found "natted" with a previous NAT
presence discovery process. The port allocation rule discovery
process uses only Test I, but applies it to different combinations of
IP addresses and ports in order to figure out the port allocation
characteristics of the NAT. A STUN server uses 2 different IP
addresses (Da and Ca) as shown in Table 7.1 and 2 different ports (Dp
and Cp). This is the minimal set required to discover the allocation
rule.
Table 7.1 Test I Destinations for Port Allocation Discovery Process
+---------------------------------+
| | Destinations |
| |-------------------------|
| | IP Address | Port |
|-------+------------+------------|
| TRY-1 | Da | Dp | <= STUN client obtains
|-------+------------+------------| Ca and Cp in CHANGED-ADDRESS
| TRY-2 | Da | Cp | attribute in the response.
|-------+------------+------------|
| TRY-3 | Ca | Dp |
|-------+------------+------------|
| TRY-4 | Ca | Cp |
+---------------------------------+
Test I is performed 4 times (TRY-1 through TRY-4) per local port.
Destinations to which the TRY-1 through TRY-4 are performed are shown
in Table 7.1. This process can be done with the same local port that
is used in the previous NAT discovery process. Since TRY-1 has
already been done in Test I, it can be skipped and testing can begin
from TRY-2. The client will obtain 4 MAPPED-ADDRESSes from the
responses. The 4 MAPPED-ADDRESSes are analyzed to determine the port
allocation rule, the delta p value, and to evaluate consistency.
To look for consistency, the process can be performed multiple times,
however, each test should be done from a different local port which
does not have a NAT binding associated with it.
The port allocation rule will be determined by looking at the port
numbers obtained from MAPPED-ADDRESSes. If all port numbers are
incremented at each test, the port allocation rule is 'Port
Sensitive'.
If the port increment size from TRY-1 and TRY-2, and the ones from
TRY-3 and TRY-4 are always 0, but the incremental size between the
ones from TRY-2 and TRY-3 are not 0, the port allocation rule is
'Address Sensitive'.
The delta p value will be determined as follows:
Takeda [Page 15]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
Cone NAT:
If all port numbers of the obtained MAPPED-ADDRESSes are the same,
the NAT is a 'Cone NAT'.
Address sensitive allocation:
The delta p is equal to a port increment size between TRY-2 and
TRY-3. If the process is re-done one more time from another local
port (TRY-5 to TRY-8 as shown in Figure 7.2), delta p should also
equal to the port increment sizes between TRY-4 and TRY-5 and
between TRY-6 and TRY-7.
Port sensitive allocation:
The delta p is the difference between adjoining port numbers of
MAPPED-ADDRESSes obatained from testing (TRY-[N+1] and TRY-[N]).
[TRY] [MAPPED-ADDRESS]
1 67.105.12.10:49152
2 67.105.12.10:49152 (+0)----+
3 67.105.12.10:49154 (+2)--+ |
4 67.105.12.10:49154 (+0)--|-+
5 67.105.12.10:49156 (+2)--+ |
6 67.105.12.10:49156 (+0)--|-+
7 67.105.12.10:49158 (+2)--+ |
8 67.105.12.10:49158 (+0)--|-+
| +-> always 0: 'Address Sensitive'
+---> consistently 2: Delta p = 2
Figure 7.2 Allocation Discovery Result: Address Sensitive
Figure 7.2 shows the result of the allocation discovery process with
a NAT that has an address sensitive allocation rule. TRY-5 through
TRY-8 are performed from a different local port than the one used in
TRY-1 through TRY-4.
In situations that the internal device could not find the consistency
with the port increment size for delta p determination, the
application needs to have an algorithm to determine the delta p value
based on statistical observation, or to decide to give up obtaining a
valid delta p. The device should be able to determine whether or not
it is address sensitive or port sensitive. The device still has a
chance to traverse the NAT if the NAT combination class is III as
described in section 5.
Takeda [Page 16]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
8 Traversing Symmetric NAT
This section describes how the symmetric NAT traversal (specifically,
class IV traversal) is accomplished. To aid in this explanation, the
following network configuration is used.
STUN Server
+-----+
NAT-S | | NAT-R
+-+ +--+--+ +-+
+----+ | | | | | +----+
|EP-S|-----+ +-----((Public Network))-----+ +-----|EP-R|
+----+ | | | | +----+
+-+ +-+
Figure 8.1 Network Configuration
There are two endpoints EP-S and EP-R, for example, that are located
behind different NATs (NAT-S and NAT-R, respectively) and EP-R wants
to receive UDP packets from EP-S.
Both EP-S and EP-R have performed NAT discovery processes and know
the following attributes of the NAT obtained from the discovery
processes described in the previous sections.
o Incoming Packet Filter Type
o Port Allocation Rule
o Delta p
8.1 Information To Be Exchanged
Incoming packet filter type attribute is used to determine whether or
not an endpoint device needs to send an invitation packet. This
attribute is not necessary for the other endpoint and need not be
exchanged.
When it comes to sending packets (including invitation packets), the
endpoint needs to know the destination address for the packets. If
the port allocation rule of the other endpoint is a symmetric type,
the endpoint needs either to record the source port number of an
incoming packet or to predict a port number that the symmetric NAT
will assign, with a MAPPED-ADDRESS obtained from the other endpoint.
The following items are the required information to be exchanged
between the endpoints (EP-S and EP-R) in order to traverse NAT
(including the class IV case).
Takeda [Page 17]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
o MAPPED-ADDRESS (from Binding Request with STUN server)
o Port Allocation Rule
o Delta p (required if port allocation rule is either address
sensitive or port sensitive)
8.2 EP-R Behavior
Soon after the information exchange is complete EP-R decides, using
the obtained information, the following items with regard to an
invitation packet transmission.
(1) If an invitation packet needs to be sent.
(2) Requirement for its repetition.
(1) is to be decided with port allocation rule of EP-S and incoming
packet filter type of EP-R as shown in Table 8.1.
Table 8.1 Invitation Packet Determination Chart for EP-R
+----------------------+-----------------------------------+
| | NAT-R Incoming Packet Filter Type |
| |-----------------------------------|
| | No | Address | Port |
| | Filter | Sensitive | Sensitive |
+----------+-----------+-----------+-----------+-----------+
| | Open | | |
| NAT-S |-----------+ + YES |
| Port | Cone | | |
|Allocation|-----------+ NO +-----------+-----------|
| Rule | Address | | | |
| | Sensitive | | YES | YES |
| |-----------+ + (*1) + (*2) |
| | Port | | | |
| | Sensitive | | | |
+----------------------+-----------------------------------+
(*1) in Table 8.1 is the case that EP-R mentioned in Figure 8.1 has a
NAT that has an address sensitive filter. Although NAT-S is a
symmetric NAT (the port shown in MAPPED-ADDRESS is invalid), EP-R can
send a packet to any port of the IP address in the MAPPED-ADDRESS.
This can be done because the NAT-R's incoming packet filter is not
sensitive to its source port.
(*2) If NAT-R has a port sensitive filter and NAT-S is a symmetric
NAT, EP-R needs to predict a specific port that will be allocated by
NAT-S later on so that EP-R can send the invitation packet to the
port.
Takeda [Page 18]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
The invitation packet is required to be sent repeatedly in case the
other endpoint (EP-S shown in Figure 8.1) needs to capture the
invitation packet to record its source port to which EP-S can send
packets afterwards.
The reason for the repetition is that when the first invitation
packet is sent from EP-R, NAT-S might not be ready to route the
packet to EP-S because EP-S hasn't sent an invitation packet yet.
Since EP-S needs to capture the packet to record its source port
number, EP-R has to make sure that EP-S receives the invitation
packet.
The condition that EP-R is required to send invitation packets
repeatedly is when NAT-R follows either address sensitive allocation
rule or port sensitive allocation rule.
The retransmission should stop when EP-R starts to receive packets
from EP-S successfully, or a time-out event set up for error handling
occurred.
NOTE: Even if NAT-R has no filter, EP-R has to send the invitation
packets repeatedly because the purpose of the invitation packet in
this case is not only for opening the filter on NAT-R for the
destination but also for informing EP-S of the source port number
allocated by NAT-R.
8.3 EP-S Behavior
Soon after the information exchange is complete, EP-S decides, with
the obtained information, the following items with regard to
invitation packet transmission:
(1) If an invitation packet needs to be sent.
(2) If source port recording is required.
EP-S only needs to send an invitation packet to EP-R when source port
recording is required and NAT-S has either address sensitive filter
or port sensitive filter (Table 8.2). By sending an invitation
packet, it opens up the filter (door) at NAT-S to NAT-R so that the
invitation packet coming from EP-R will be received at EP-S.
Source port recording is required if and only if NAT-S has either
address sensitive allocation rule or port sensitive allocation rule.
Takeda [Page 19]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
Table 8.2 Invitation Packet Determination Chart for EP-S
+----------------------+-----------------------------------+
| | NAT-S Incoming Packet Filter Type |
| |-----------------------------------|
| | No | Address | Port |
| | Filter | Sensitive | Sensitive |
+----------+-----------+-----------+-----------+-----------+
| | Open | | |
| NAT-R |-----------+ + YES |
| Port | Cone | | |
|Allocation|-----------+ NO +-----------+-----------|
| Rule | Address | | | |
| | Sensitive | | YES | YES |
| |-----------+ + (*3) + (*4) |
| | Port | | | |
| | Sensitive | | | |
+----------------------+-----------------------------------+
(*3) in Table 8.2 is the case in which EP-S mentioned in Figure 8.1
has a NAT that has an address sensitive filter. Although NAT-R is a
symmetric NAT (the port shown in MAPPED-ADDRESS is invalid), EP-S can
send a packet to any port of the IP address in the MAPPED-ADDRESS.
This can be done because the incoming packet filter for NAT-S is not
sensitive to its source port.
(*4) If NAT-S has a port sensitive filter and NAT-R is a symmetric
NAT, EP-S needs to predict a specific port that will be allocated by
NAT-R later on so that EP-S can send the invitation packet to the
port.
8.4 Increasing Prediction Success Rate
In order to increase success rate of the port prediction for
symmetric NATs, invitation packets can be sent to multiple
destinations that are possible next ports to be allocated by
symmetric NATs.
For example, NAT-R has a port sensitive filter and a port sensitive
allocation rule. NAT-S has a port sensitive filter and an address
allocation rule. In this case, source port recording is required. In
order for EP-S to capture an invitation packet from EP-R, EP-S sends
an invitation packet to a predicted port on NAT-R. The prediction is
typically made by adding delta p to the port number of the MAPPED-
ADDRESS obtained from EP-R earlier.
As mentioned in section 6.1, a symmetric NAT might not allocate the
predicted port number because the port might be in use and skipped to
Takeda [Page 20]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
the next one (+2 * delta p). For that reason, EP-S can send
invitation packets not only to +delta p, but also to the next
possible ports such as +2*delta p, +3*delta p,...as shown below.
NAT-S _____ MAPPED- ____ NAT-R
+------+ / ADDRESS \ +------+
| |/ \| |
| 4000 @ @ 6000 |
EP-S | | +1*delta p | | EP-R
+--+ | 4001 @-+------------------->x 6002 | +--+
| | | | \ +2*delta p | | | |
| +----| | +----------------->x 6004 +----+ |
| | | | \ +3*delta p | | | |
+--+ | | +--------------->x 6006 | +--+
| | \ +4*delta p | |
| | -------------->x 6008 |
| | | |
+------+ +------+
- PS filter - PS filter
- AS allocation - PS allocation
- delta p = 1 - delta p = 2
Figure 8.2 Invitation Packets To Multiple Predicted Ports
Sending invitation packets to multiple predicted ports is possible
because NAT-S will not create a new port each time it sends an
invitation packet to NAT-R. This means that if NAT-S is a port
restricted-cone NAT, the method will still work.
If NAT-S has a port sensitive allocation rule and a port sensitive
filter, this additional invitation packet does not help increase the
success rate. Each time EP-S sends an invitation packet to a
different port, EP-S allocates another port. The whole purpose of
sending invitation packets to multiple ports on NAT-R is to have one
specific port accept incoming packets from the multiple ports on NAT-
R. New allocations on NAT-S defeat this purpose.
In Figure 8.3, EP-S is sending an invitation packet to multiple ports
on NAT-R, assuming that when EP-R sends an invitation packet to NAT-
S, NAT-R will allocate one of these ports (6000 through 6008) for the
packet. If NAT-R allocated 6004 when EP-R sends an invitation packet
to 4001 on NAT-S, for example, as NAT-S has port sensitive filter and
4001 never sent a packet to 6004, it blocks the incoming packet.
Takeda [Page 21]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
NAT-S _____ MAPPED- ____ NAT-R
+------+ / ADDRESS \ +------+
| |/ \| |
| 4000 @ @ 6000 |
EP-S | | +1*delta p | | EP-R
+--+ | 4001 @--------------------->x 6002 | +--+
| | | | +2*delta p | | | |
| @----| 4002 @--------------------->x 6004 +----@ |
| | | | +3*delta p | | | |
+--+ | 4003 @--------------------->x 6006 | +--+
| | +4*delta p | |
| 4004 @--------------------->x 6008 |
| | | |
+------+ +------+
- PS filter - PS filter
- PS allocation - PS allocation
- delta p = 1 - delta p = 2
Figure 8.3 Invitation Packets To Multiple Predicted Ports
The benefit of knowing which allocation rule (address sensitive or
port sensitive) a symmetric NAT has is that the discovery of the
address sensitive allocation rule will increase the success rate of
the port prediction.
Takeda [Page 22]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
9 Normative Reference
[1] Rosenberg, et al. "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators (NATs)" RFC 3489,
March 2003.
[2] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-
rosenberg-midcom-turn-00.txt, November 2001.
[3] D. Yon, "Connection-oriented media transport in SDP," Internet
Draft, Internet Engineering Task Force, May 2002. Work in progress.
[4] Rosenberg, et al. "NAT and Firewall Scenario and Solutions for
SIP", draft-ietf-sipping-nat-scenarios-00.txt, IETF, June 24, 2002.
[5] M. Handley, V. Jacobson, "Session Description Protocol (SDP)",
IETF RFC 2327, April 1998.
[6] P. Srisuresh, K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)," RFC 3022, Internet Engineering Task
Force, January 2001.
[7] J. Postel, "internet protocol", RFC 791, Internet Engineering
Task Force, September 1981.
Takeda [Page 23]
Internet-Draft Symmetric NAT Traversal using STUN June 2003
10 Author's Address
Yutaka Takeda
Panasonic Communications Research Laboratory
10993 Via Frontera
San Diego, CA 92127
EMail: takeday@kmerl.com
Takeda [Page 24]
浙公网安备 33010602011771号