NAT Behavior Discovery Using
STUNCounterPath Solutions, Inc.Suite 300, One Bentall Centre, 505 Burrard StVancouverV7X1M3BCCanada+1-604-320-3344derek.macdonald@gmail.comMYMIC LLC1040 University Blvd., Suite 100PortsmouthVA23703USAbbl@lowekamp.net
Transport Area
BEHAVEnat type diagnosticsDraftThis specification defines an experimental usage of the Session
Traversal Utilities for NAT (STUN) Protocol that discovers the presence
and current behaviour of NATs and firewalls between the STUN client and
the STUN server.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 RFC 2119.This experimental NAT Behavior Discovery STUN usage provides
information about a NAT device's observable transient behavior; it
determines a NAT's behavior with regard to the STUN server used and the
particular client ports used at the instant the test is run. This STUN
usage does not allow an application behind a NAT to make an absolute
determination of the NAT’s characteristics. NAT devices do not
behave consistently enough to predict future behaviour with any
guarantee. Applications requiring reliable reach between two particular
endpoints must establish a communication channel through NAT using
another technique. IETF has proposed standards including ICE and OUTBOUND for establishing
communication channels when a publicly accessible rendezvous service is
available.The primary uses envisioned for the STUN attributes included in this
draft are diagnostics and real-time tuning of applications. The
techniques possible with this usage are powerful diagnostic tools in the
hands of a network administrator or system programmer trying to
determine the causes of network failure; particularly when behavior
varies by load, destination, or other factors that may be related to NAT
behavior.This draft also proposes experimental usage of these attributes for
real-time optimization of parameters for protocols in situations where a
publicly accessible rendezvous service is not available. Such a use of
these techniques is only possible when the results are applied as an
optimization and a reliable fallback is available in case the NAT's
behavior becomes more restrictive than determined by the Behavior
Discovery tests. One possible application is role selection in P2P
networks based on statistical experience with establishing direct
connections and diagnosing NAT behavior with a variety of peers. The
experimental question is whether such a test is useful. If a node trying
to join an overlay as a full peer when its NAT prevents sufficient
connectivity and then withdrawing is expensive or leads to unreliable or
poorly performing operation, then even if the behavior discovery check
is only "correct" 75% of the time, its relative cheapness may make it
very useful for optimizing the behavior of the overlay network. Section
describes this
experimental application in more detail and discusses how to evaluate
its success or failure. The applications of this STUN usage differ from the original use of
STUN (originally RFC3489, now RFC5389). This specification acknowledges that
the information gathered in this usage is not, and cannot be, correct 100%
of the time, whereas STUN focused only on getting information that could
be known to be correct and static. This specification can also be compared to ICE. ICE requires a
fallback to TURN be available wheras 3489-based applications tried to
determine in advance whether they would need a relay and what their peer
reflexive address will be, which is not generally achievable. be, which
are both impossible. This STUN usage requires an application using it to
have a fallback, but unlike ICE's focus on the problems inherent in VoIP
sessions, doesn't assume that it will only be used to establish a
connection between a single pair of machines, and so alternative fallback
mechanisms may make sense. For example, in a P2P application it may be
possible to simply switch out of the role where such connections need to
be established or to select an alternative indirect route if the peer
discovers that, in practice, 10% of its connection attempts fail.It is submitted to the Internet community as an experimental protocol
that, when applied with appropriate statistical underpinnings and
application behavior that is ultimately based on experienced
connectivity patterns, can lead to more stability and increased
performance than is available without the knowledge it provides.If a standards document specifies the use of any portion of this STUN
usage, that document MUST describe how incorrect information derived using
these methods will be managed, either through identifying when a NAT's
behavior changed or because the protocol uses such knowledge as an
optimization but remains functional when the NAT's behavior changes. The
referencing document MUST also define when the fallback mechanism will be
invoked. Applications in different domains may vary greatly in how
agressively the fallback mechanism is utilized, so there must be a
clear defintion of when the fallback mechanism is invoked.The Session Traversal Utilities for NAT (STUN)
provides a mechanism to discover the reflexive transport address
toward the STUN server, using the Binding Request. This specification
defines the NAT Behavior Discovery STUN usage, which allows a STUN client
to probe the current behaviour of the NAT/Firewall devices between the
client and the STUN server. This usage defines new STUN attributes for the
Binding Request and Binding Response.Many NAT/FW devices do not behave consistently and will change their
behaviour under load and over time. Applications requiring high
reliability must be prepared for the NAT's behaviour to become more
restrictive. Specifically, it has been found that under load NATs may
transition to the most restrictive filtering and mapping behaviour and
shorten the lifetime of new and existing bindings. In short,
applications can discover how bad things currently are, but not how bad
things will get.Despite this limitation, instantaneous observations are often quite
useful in troubleshooting network problems, and repeated tests over
time, or in known load situations, may be used to characterize a NAT's
behavior. In particular, in the hands of a person knowledgeable about
the needs of an application and the nodes an application needs to
communicate with, it can be a powerful tool.Applications that work well in the lab, but fail in a deployment,
are notoriously common within distributed systems. There are few
systems developers who have not had the experience of searching to
determine the difference in the environments for insight as to what
real-network behavior was missed in the testing lab. The behavior
discovery usage offers a powerful tool that can be used to check NAT
and firewall behavior as the application is running. For example, an
application could be designed to perform Behavior Discovery tests
whenever it experiences significant communications problems when
running. Such analysis might be included as part of the diagnostic
information logged by the application.As they are being used to detect instantaneous behavior for
analysis by an experienced developer or administrator, there are
relatively few concerns about this application of the NAT Behavior
Discovery STUN usage. However, the user should be aware thatadding new traffic to new destinations (STUN servers) has the
potential to itself change the behavior of a NAT andthe user must be careful to select a STUN server that is
appropriately located, ideally collocated (or even integrated)
with the communication partners of the application in question,
for the results to be applicable to the network conditions
experienced by the application.An application could use Behavior Discovery in a Peer-to-Peer (P2P)
protocol to determine if a particular endpoint is a reasonable
candidate to participate as a peer or supernode (defined here as a
peer in the overlay that offers services, including message routing,
to other members or clients of the overlay network). This P2P network
application is willing to select supernodes that might be located
behind NATs to avoid the cost of dedicated servers. A supernode
candidate requires that its NAT(s) offer(s) Endpoint-Independent
Filtering. It might periodically re-run tests and would remove itself
as a supernode if its NAT/FW chain lost this characteristic. These
tests could be run with other supernodes acting as STUN servers as
well as with dedicated STUN servers. As many P2P algorithms tolerate
non-transitive connectivity between a portion of their peers,
guaranteed pair-wise reliable reach might be sacrificed in order to
distribute the P2P overlay's load across peers that can be directly
contacted by the majority of users.Consider an example from a hypothetical P2P protocol in more
detail: When P2P node A starts up, it tests its NAT(s) relative to
other peers already in the overlay. If the results of its testing
indicate A is behind a "good" NAT (with endpoint-independent mapping
and filtering), A will join the overlay and establish connections with
appropriate peers in the overlay to join the overlay's topology.
Although A is reachable by routing messages across the overlay
topology, A will also include in its communication with other nodes
that they may reach it directly using its reflexive IP address (or
addresses) that A discovered in its initial testing. Suppose that
later, node B wants to send a message to A, and B is not a neighbor of
A in the overlay topology. B may send the message directly to A's IP
address and start a timer. If B doesn't receive a response within a
certain amount of time, then it routes the message to A across the
overlay instead and includes a flag that indicates a direct connection
was attempted but failed. (Alternatively, B could simultaneously send
the message to A's IP address and across the overlay, which guarantees
minimum response latency, but can waste bandwidth.) A over time
observes the percentage of successful direct messages it receives out
of those attempted. If the percentage of successful direct connections
is below some threshold (perhaps 75%), then A may stop advertising for
direct connections because it has determined in practice that its NATs
are not providing sufficiently reliable connectivity to justify the
cost of attempting the direct message. But if the percentage is high
enough, A continues to advertise because the successful direct
connections are improving the overlay's performance by reducing the
routing load imposed on the overlay. If at some point, A's NAT(s)
changes behavior, A will notice a change in its percentage of
successful direct connections and may re-evaluate its decision to
advertise a public address. In this hypothetical example, Behavior
Discovery is used for A's initial operating mode selection, but the
actual decision for whether to continue advertising that public
IP/port pair is made based on actual operating data. The results of
the behavior-discovery usage are also used as a performance
optimization, as A is at all times able to establish connectivity
through the overlay if the attempted direct connection fails.Use of Behavior Discovery for such an
application requires:Use of a protocol capable of offering reliable end-user
performance using unreliable links between peers.A protocol offering a reliable fallback to connections
attempted based on the results of Behavior Discovery probing.The application is deployed behind NATs that provide
Endpoint-Independent Filtering and that remain in this mode for an
amount of time sufficient for the application to identify their
behavior, distribute this information to the rest of the overlay,
and provide useful work for the application.This draft is experimental as applications implementing open
protocols have yet to be deployed in such environments to demonstrate
that these three requirements have been met. However, anecdotal evidence
suggests that NATs targeted at households and small businesses have
stable behaviour, especially when there are few clients behind them.
Numerous P2P applications have been deployed that appear to have these
properties, although their protocols have not yet been subjected to
rigorous evaluation by standards bodies.The criteria for an application to successfully demonstrate use of
the NAT Behavior Discovery STUN usage would include:An implementation that relies on this usage to determine its
run-time behavior, most likely using it to determine an initial
choice of options that are then adjusted based on experience with
its network connections.The implementation must either demonstrate its applicability in
environments where it is realistic to expect a provider to deploy
dedicated STUN servers with multiple IP addresses, or it must
demonstrate duplicating the behavior of such a dedicated STUN
server with two nodes that share the role of providing the
address-changing operations required by this usage.Experimental evidence that the application of this usage
results in improved behavior of the application in real-world
conditions. The exact metrics for this improvement may vary, some
possibilities include: faster convergence to the proper
parameters, less work to set up initial connections, fewer
reconfigurations required after startup, etc.A protocol specification that defines how the implementation
applies this usage.The P2P scenario described above is a likely experimental
test case for this usage, but others applications are possible as
well.In a typical configuration, a STUN client is connected to a private
network and through one or more NATs to the public Internet. The client
is configured with the address of a STUN server on the public Internet.
The Behavior Discovery usage makes use of SRV records so that a server
may use a different transport address for this usage than for other
usages. This usage does not provide backward compatibility with RFC3489 for either clients or servers.
Implementors of clients that wish to be compliant with RFC3489 servers
should see that specification. Implementors of servers SHOULD NOT
include support for RFC3489 clients as the original uses of that
protocol have been deprecated.Because the STUN forbids a server from creating a new TCP or TCP/TLS
connection to the client, many tests apply only to UDP. The
applicability of the various tests is indicated below.The STUN NAT Behavior Discovery usage defines new attributes on the
STUN Binding Request and STUN Binding Response that allow these messages
to be used to diagnose the current behavior of the NAT(s) between the
client and server.This section provides a descriptive overview of the typical use of
these attributes. Normative behavior is described in Sections , and .A client behind a NAT wishes to determine if the NAT it is behind
is currently using endpoint-independent, address-dependent, or address
and port-dependent mapping. The client
performs a series of tests that make use of the OTHER-ADDRESS
attribute; these tests are described in detail in . These tests send
binding requests to the alternate address and port of the STUN server
to determine mapping behaviour. These tests can be used for UDP, TCP,
or TCP/TLS connections.A client behind a NAT wishes to determine if the NAT it is behind
is currently using endpoint-independent, address-dependent, or address
and port-dependent filtering. The client
performs a series of tests that make use of the OTHER-ADDRESS and
CHANGE-REQUEST attributes; these tests are described in . These tests request
responses from the alternate address and port of the STUN server; a
precondition to these tests is that no binding be established to the
alternate address and port. See below for more information. Because
the NAT does not know that the alternate address and port belong to
the same server as the primary address and port, it treats these
responses the same as it would those from any other host on the
Internet. Therefore, the success of the binding responses sent from
the alternate address and port indicate whether the NAT is currently
performing endpoint-independent filtering, address-dependent
filtering, or address and port-dependent filtering. This test applies
only to UDP datagrams.Many systems, such as VoIP, rely on being able to keep a connection
open between a client and server or between peers of a P2P system.
Because NAT bindings expire over time, keepalive messages must be sent
across the connection to preserve it. Because keepalives impose some
overhead on the network and servers, reducing the frequency of
keepalives can be useful.A normal request-response protocol cannot be used to test binding
lifetime because the initial request resets the binding timer.
Behavior Discover defines the RESPONSE-PORT attribute to allow
the client and server to set up a "control channel" using one port on
the client that is used to test the binding lifetime of a different
port allocated on the client. More generally, RESPONSE-PORT
allows the client to allocate two ports and request that responses to
queries sent from one port be delivered to the other. The client uses
its second port and the STUN server's alternate address to check if an
existing binding that hasn't had traffic sent on it is still open
after time T. This approach is described in detail in . This test applies only to UDP
datagrams.STUN Binding Requests allow a client to determine whether it is
behind a NAT that supports hairpinning of connections. To perform this
test, the client first sends a Binding Request to its STUN server to
determine its mapped address. The client then sends a STUN Binding
Request to this mapped address from a different port. If the client
receives its own request, the NAT hairpins connections. This test
applies to UDP, TCP, or TCP/TLS connections.Some NATs exhibit different behavior when forwarding fragments than
when forwarding a single-frame datagram. In particular, some NATs do
not hairpin fragments at all and some platforms discard fragments
under load. To diagnose this behavior, STUN messages may be sent with
the PADDING attribute, which simply inserts additional space into the
message. By forcing the STUN message to be divided into multiple
fragments, the NAT's behavior can be observed.All of the previous tests can be performed with PADDING if a NAT's
fragment behavior is important for an application, or only those tests
which are most interesting to the application can be retested. PADDING
only applies to UDP datagrams. PADDING can not be used with
RESPONSE-PORT.A number of NAT boxes are now being deployed into the market which
try to provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This behavior can be detected
because the STUN server returns both the MAPPED-ADDRESS and
XOR-MAPPED-ADDRESS in the same response. If the result in the two does
not match, there is a NAT with a generic ALG in the path. This test
apples to UDP and TCP, but not TLS over TCP connections.This section provides a descriptive overview of how the NAT Behavior
Discovery usage primitives allow checks to be made to discover the
current behaviour of the NAT or NATs an application is behind. These
tests can only give the instantaneous behaviour of a NAT; it has been
found that NATs can change behaviour under load and over time. The
results of these tests therefore can be regarded as upper bounds---an
application must assume that NAT behaviour can become more restrictive
at any time. Results from tests performed using a particular port on the
client may also not indicate the behavior experienced by a different
port, as described in.Definitions for NAT filtering and mapping behaviour are from . The tests described here are for UDP
connectivity, NAT mapping behaviour, NAT filtering behaviour, and NAT
binding lifetime discovery; additional tests could be designed using
this usage's mechanisms. The tests described below include only tests
that can be performed using a client with a single IP address. A client
with multiple IP addresses (or multiple clients collaborating) behind
the same NAT can combine their probes to test additional aspects of NAT
behavior, such as port overloading. This section provides a descriptive
overview of how the primitives provided by the STUN attributes in this
specification may be used to perform behavior tests.Normative specifications for the attributes are defined in later
sections.Proper source port selection is important to ensuring the
usefulness and accuracy of the Behavior Discovery tests. There are two
preconditions for tests:Because mapping behavior can vary on a port-by-port basis, an
application should perform its tests using the source port
intended for use by the application whenever possible. If it
intends to use multiple source ports, it should repeat these tests
for each source port. Such tests should be performed sequentially
to reduce load on the NAT.Because the results of some diagnostic checks depend on
previous state in the NAT created by prior traffic, the tests
should be performed using a source port that has not generated
recent traffic. Therefore the application should use a random
source port or ensure that no traffic has previously occurred on
the selected port prior to performing tests, generally by
allocating a port and holding it unused for at least 15 minutes
prior to the tests.Ensuring both of these preconditions can be challenging,
particularly for a device or application wishing to perform Behavior
Discovery tests at startup. The following guidelines are suggested for
reducing the likelihood of problems:An application intended to operate behind a NAT should not
attempt to allocate a specific or well-known port. Because such
software must be designed to interoperate using whatever port is
mapped to it by the NAT, the specific port is unnecessary.
Instead, on startup a random port should be selected (see below
for recommended ranges). An application, particularly on an
embedded device, should not rely on the host operating system to
select the next available port, because that might result in the
application receiving the same port on each restart. An
application using the same port between restarts may not receive
accurate results from Behavior Discovery tests that are intended
to test state-related behavior of NATs, such as filtering and
binding lifetime.An application requiring multiple ports, such as separate ports
for control and media, should allocate those ports on startup when
possible. Even if there is no immediate need for media flow, if
Behavior Discovery tests will be run on those ports, allocating
them early will allow them to be left idle, increasing the chance
of obtaining accurate results from Behavior Discovery tests.Although the most reliable results are obtained when performing
tests with the specific ports that the application will use, in
many cases an application will need to allocate and use ports
without being able to perform complete Behavior Discovery tests on
those ports. In those cases, an application should randomly select
its ports from a range likely to receive the same treatment by the
NAT. This document recommends ranges of 32768-49151, which is the
upper end of IANA's Registered Ports range, and 49152-65535, which
is IANA's Dynamic and/or Private port range, for random selection.
To attempt to characterize a NAT's general treatment of ports in
these ranges, a small number of ports within a range can be
randomly selected and characterized.Those tests particularly sensistive to prior state on a NAT
will be indicated below.The client sends a STUN Binding Request to a server. This causes
the server to send the response back to the address and port that the
request came from. If this test yields no response, the client knows
right away that it does not have UDP connectivity with the STUN
server. This test requires only STUN
functionality.This will require at most three tests. In test I, the client
performs the UDP connectivity test. The server will return its
alternate address and port in OTHER-ADDRESS in the binding response.
If OTHER-ADDRESS is not returned, the server does not support this
usage and this test cannot be run. The client examines the
XOR-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 NATed and the effective mapping will
be Endpoint-Independent.In test II, the client sends a Binding Request to the alternate
address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding
Response is the same as test I the NAT currently has
Endpoint-Independent Mapping. If not, test III is performed: the
client sends a Binding Request to the alternate address and port. If
the XOR-MAPPED-ADDRESS matches test II, the NAT currently has
Address-Dependent Mapping; if it doesn't match it currently has
Address and Port-Dependent Mapping.This will also require at most three tests. These tests are
sensitive to prior state on the NAT.In test I, the client performs the UDP connectivity test. The
server will return its alternate address and port in OTHER-ADDRESS in
the binding response. If OTHER-ADDRESS is not returned, the server
does not support this usage and this test cannot be run.In test II, the client sends a binding request to the primary
address of the server with the CHANGE-REQUEST attribute set to
change-port and change-IP. This will cause the server to send its
response from its alternate IP address and alternate port. If the
client receives a response the current behaviour of the NAT is
Endpoint-Independent Filtering.If no response is received, test III must be performed to
distinguish between Address-Dependent Filtering and Address and
Port-Dependent Filtering. In test III, the client sends a binding
request to the original server address with CHANGE-REQUEST set to
change-port. If the client receives a response the current behaviour
is Address-Dependent Filtering; if no response is received the current
behaviour is Address and Port-Dependent Filtering.Clients may wish to combine and parallelize these tests to reduce
the number of packets sent and speed the discovery process. For
example, test I of the filtering and mapping tests also checks if UDP
is blocked. Furthermore, an application or user may not need as much
detail as these sample tests provide. For example, establishing
connectivity between nodes becomes significantly more difficult if a
NAT has any behavior other than endpoint-independent mapping, which
requires only test I and II of .
An application determining its NAT does not always provide independent
mapping might notify the user if no relay is configured, whereas an
application behind a NAT that provides endpoint-independent mapping
might not notify the user until a subsequent connection actually fails
or might provide a less urgent notification that no relay is
configured. Such a test does not alleviate the need for ICE, but it does provide some
information regarding whether ICE is likely to be successful
establishing non-relayed connections.Care must be taken when combining and parallelizing tests, due to
the sensitivity of certain tests to prior state on the NAT and because
some NAT devices have an upper limit on how quickly bindings will be
allocated. restricts the rate
at which clients may begin new STUN transactions.STUN can also be used to probe the lifetimes of the bindings
created by the NAT. Such tests are sensitive to prior state on the
NAT. For many NAT devices, an absolute refresh interval cannot be
determined; bindings might be closed quicker under heavy load or might
not behave as the tests suggest. For this reason applications that
require reliable bindings must send keep-alives as frequently as
required by all NAT devices that will be encountered. Suggested
refresh intervals are outside the scope of this document. ICE and OUTBOUND have suggested refresh
intervals.Determining the binding lifetime relies on two separate source
ports being used to send STUN Binding Requests to the STUN server. The
general approach is that the client uses a source port X to send a
single Binding Request. After a period of time during which source
port X is not used, the client uses a second source port Y to send a
Binding Request to the STUN server that indicates the response should
be sent to the binding established to port X. If the binding for port
X has timed out, that response will not be received. By varying the
time between the original Binding Request sent from X and the
subsequent request sent from Y, the client can determine the binding
lifetime.To determine the binding lifetime, the client first sends a Binding
Request to the server from a particular source port, X. This creates a
binding in the NAT. The response from the server contains a
MAPPED-ADDRESS attribute, providing the public address and port on the
NAT. Call this Pa and Pp, respectively. The client then starts a timer
with a value of T seconds. When this timer fires, the client sends
another Binding Request to the server, using the same destination
address and port, but from a different source port, Y. This request
contains an RESPONSE-PORT attribute, set to Pp, to request the response
be delivered to (Pa,Pp). This will create a new binding on the NAT, and
cause the STUN server to send a Binding Response that would match the
old binding, (Pa,Pp), if it still exists. If the client receives the
Binding Response on port X, it knows that the binding has not
expired. If the client receives the Binding Response on port Y (which is
possible if the old binding expired, and the NAT allocated the same
public address and port to the new binding), or receives no response at
all, it knows that the binding has expired.Because some NATs only refresh bindings when outbound traffic is
sent, the client must resend a binding request from the original
source port before beginning a second test with a different value of
T. The client can find the value of the binding lifetime by doing a
binary search through T, arriving eventually at the value where the
response is not received for any timer greater than T, but is received
for any timer less than T. Note also that the binding refresh behavior
(outbound only or all traffic) can be determined by sending multiple
Binding Requests from port Y without refreshes from the original
source port X.This discovery process takes quite a bit of time and is something
that will typically be run in the background on a device once it
boots.It is possible that the client can get inconsistent results each
time this process is run. For example, if the NAT should reboot, or be
reset for some reason, the process may discover a lifetime than is
shorter than the actual one. Binding lifetime may also be dependent on
the traffic load on the NAT. For this reason, implementations are
encouraged to run the test numerous times and be prepared to get
inconsistent results.Like the other diagnostics, this test is inherently unstable. In
particular, an overloaded NAT might reduce binding lifetime to shed
load. A client might find this diagnostic useful at startup, for
example setting the initial keepalive interval on its connection to
the server to 10 seconds while beginning this check. After determining
the current lifetime, the keepalive interval used by the connection to
the server can be set to this appropriate value. Subsequent checks of
the binding lifetime can then be performed using the keepalives in the
server connection. The STUN Keepalive Usage provides a response that
confirms the connection is open and allows the client to check that
its mapped address has not changed. As that provides both the
keepalive action and diagnostic that it is working, it should be
preferred over any attempt to characterize the connection by a
secondary technique.Unless otherwise specified here, all procedures for preparing,
sending, and processing messages as described in the STUN Binding Usage
are followed.As support for RESPONSE-PORT is optional a client MUST be
prepared to receive a 420 (Unknown Attribute) error to requests that
include RESPONSE-PORT. Support for OTHER-ADDRESS
and CHANGE-REQUEST is optional, but MUST be supported by servers
advertised via SRV, as described below. This is to allow the use of
PADDING and RESPONSE-PORT in applications where servers do not have
multiple IP addresses. Clients MUST be prepared to receive a 420 for
requests that include CHANGE-REQUEST when OTHER-ADDRESS was not received
in Binding Response messages from the server.If an application makes use of the NAT Behavior Discovery STUN usage
by multiplexing it in a flow with application traffic, a FINGERPRINT
attribute SHOULD be included unless it is always possible to distinguish
a STUN message from an application message based on their header.When PADDING is used, it SHOULD be equal to the MTU of the outgoing
interface.Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response
unless they are using authentication with a provider of STUN servers
that is aware of the topology requirements of the tests being
performed.A client SHOULD NOT generate more than ten new STUN transactions per
second and SHOULD pace them such that the RTOs do not synchronize the
retransmissions of each transaction.Unless the user or application is aware of the transport address of
a STUN server supporting the NAT Behavior Discovery usage through
other means, a client is configured with the domain name of the
provider of the STUN servers. The domain is resolved to a transport
address using SRV procedures . The
mechanism for configuring the client with the domain name of the STUN
servers or of acquiring a specific transport address is out of scope
for this document.For the Behavior Discovery Usage the service name is
"stun-behavior" for UDP and TCP. The service name is "stun-behaviors"
for TLS over TCP. Only "tcp" is defined as a protocol for
"stun-behaviors". Other aspects of handling failures and default ports
are followed as described in STUN.Servers MAY require authentication before allowing a client to make
use of its services. The method for obtaining these credentials, should
the server require them, is outside the scope of this usage. Presumably,
the administrator or application relying on this usage should have its
own method for obtaining credentials. If the client receives a 401
(Unauthorized) Response to a Request, then it must either acquire the
appropriate credential from the application before retrying or report a
permanent failure. Procedures for encoding the MESSAGE-INTEGRITY
attribute for a request are described in STUN.Unless otherwise specified here, all procedures for preparing,
sending, and processing messages as described for the STUN Binding Usage
of STUN are followed.A server implementing the NAT Behavior Discovery usage SHOULD be
configured with two separate IP addresses on the public Internet. On
startup, the server SHOULD allocate a pair of ports for each of the UDP,
TCP, and TCP/TLS transport protocols, such that it can send and receive
datagrams using the same ports on each IP address (normally a wildcard
binding accomplishes this). TCP and TCP/TLS MUST use different ports. If
a server cannot allocate the same ports on two different IP address,
then it MUST NOT include an OTHER-ADDRESS attribute in any Response and
MUST respond with a 420 (Unknown Attribute) to any Request with a
CHANGE-REQUEST attribute. A server with only one IP address MUST NOT be
advertised using the SRV service name "stun-behavior" or
"stun-behaviors".After performing all authentication and verification steps the
server begins processing specific to this Usage if the Request
contains any request attributes defined in this document:
RESPONSE-PORT, CHANGE-REQUEST, or PADDING. If the
Request does not contain any attributes from this document,
OTHER-ADDRESS and RESPONSE-ORIGIN are still included in the
response.The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS
in its Response.If the Request contains CHANGE-REQUEST attribute and the server
does not have an alternate address and port as described above, the
server MUST generate an error response of type 420.The source address and port of the Binding Response depend on the
value of the CHANGE-REQUEST attribute and on the address and port the
Binding Request was received on, and are summarized in .Let A1 and A2 be the two IP addresses used by the server and P1 and
P2 be the ports used by the server. Let Da represent the destination
IP address of the Binding Request (which will be either A1 or A2), and
Dp represent the destination port of the Binding Request (which will
be either P1 or P2). Let Ca represent the other address, so that if Da
is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let Cp represent
the other port, so that if Dp is P1, Cp is P2. If Dp is P2, Cp is P1.
If the "change port" flag was set in CHANGE-REQUEST attribute of the
Binding Request, and the "change IP" flag was not set, the source IP
address of the Binding Response MUST be Da and the source port of the
Binding Response MUST be Cp. If the "change IP" flag was set in the
Binding Request, and the "change port" flag was not set, the source IP
address of the Binding Response MUST be Ca and the source port of the
Binding Response MUST be Dp. When both flags are set, the source IP
address of the Binding Response MUST be Ca and the source port of the
Binding Response MUST be Cp. If neither flag is set, or if the
CHANGE-REQUEST attribute is absent entirely, the source IP address of
the Binding Response MUST be Da and the source port of the Binding
Response MUST be Dp.FlagsSource AddressSource PortOTHER-ADDRESSnoneDaDpCa:CpChange IPCaDpCa:CpChange portDaCpCa:CpChange IP and Change portCaCpCa:CpThe server MUST add a RESPONSE-ORIGIN attribute to the Binding
Response, containing the source address and port used to send the
Binding Response.If the server supports an alternate address and port the server
MUST add an OTHER-ADDRESS attribute to the Binding Response. This
contains the source IP address and port that would be used if the
client had set the "change IP" and "change port" flags in the Binding
Request. As summarized in , these are Ca
and Cp, respectively, regardless of the value of the CHANGE-REQUEST
flags.If the Request contained a PADDING attribute, PADDING MUST be
included in the Binding Response. The server SHOULD use a length of
PADDING equal to the MTU on the outgoing interface, rounded up to an
even multiple of four bytes. If the Request also contains the
RESPONSE-PORT attribute the server MUST return an error response
of type 400.Following that, the server completes the remainder of the
processing from STUN. If authentication
is being required, the server MUST include a MESSAGE-INTEGRITY and
associated attributes as appropriate. A FINGERPRINT attribute is only
required if the STUN messages are being multiplexed with application
traffic that requires use of a FINGERPRINT to distinguish STUN
messages.An ALTERNATE-SERVER attribute MUST NOT be included with any other
attribute defined in this specification.When the server sends the Response, it is sent from the source
address as determined above and to the to the source address of the
Request. If RESPONSE-PORT is present the server sends the reponse to
that port instead of the originating port.This document defines several STUN attributes that are required for
NAT Behavior Discovery. These attributes are all used only with Binding
Requests and Binding Responses. CHANGE-REQUEST was originally defined in
RFC3489 but is redefined here as that
document is obsoleted by .Whenever an attribute contains a transport IP address and port, it
has the same format as MAPPED-ADDRESS. Similarly, the XOR- attributes
have the same format as XOR-MAPPED-ADDRESS.The CHANGE-REQUEST attribute contains two flags to control the IP
address and port the server uses to send the response. These flags are
called the "change IP" and "change port" flags. The CHANGE-REQUEST
attribute is allowed only in the Binding Request. The "change IP" and
"change port" flags are useful for determining the current filtering
behavior of a NAT. They instruct the server to send the Binding
Responses from the alternate source IP address and/or alternate port.
The CHANGE-REQUEST attribute is optional in the Binding Request.The attribute is 32 bits long, although only two bits (A and B) are
used:The meanings of the flags are:This is the "change IP" flag. If true, it
requests the server to send the Binding Response with a different
IP address than the one the Binding Request was received on.This is the "change port" flag. If true, it
requests the server to send the Binding Response with a different
port than the one the Binding Request was received on.The RESPONSE-ORIGIN attribute is inserted by the server and
indicates the source IP address and port the response was sent from.
It is useful for detecting double NAT configurations. It is only
present in Binding Responses.The OTHER-ADDRESS attribute is used in Binding Responses. It
informs the client of the source IP address and port that would be
used if the client requested the "change IP" and "change port"
behavior. OTHER-ADDRESS MUST NOT be inserted into a Binding Response
unless the server has a second IP address.OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS
from RFC3489 because it is simply a new
name with the same semantics as CHANGED-ADDRESS. It has been renamed
to more clearly indicate its function.The REPONSE-PORT attribute contains a port. The RESPONSE-PORT
attribute can be present in the Binding Request and indicates which port
the Binding Response will be sent to. For servers which support the
RESPONSE-PORT attribute, the Binding Response MUST be transmited to the
source IP address of the Binding Request and the port contained in
RESPONSE-PORT. It is used in tests such as . When not present, the server sends
the Binding Response to the source IP address and port of the Binding
Request. The server MUST NOT process a request containing a
RESPONSE-PORT and a PADDING attribute. The RESPONSE-PORT attribute is
optional in the Binding Request. Server support for RESPONSE-PORT is
optional. RESPONSE-PORT is a 16 bit unsigned integer in network byte order followed by
2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65536.The PADDING attribute allows for the entire message to be padded to
force the STUN message to be divided into IP fragments. PADDING
consists entirely of a freeform string, the value of which does not
matter. PADDING can be used in either Binding Requests or Binding
Responses.PADDING MUST NOT be longer than the length that brings the total IP
datagram size to 64K. It SHOULD be equal in length to the MTU of the
outgoing interface, rounded up to an even multiple of four bytes.
Because STUN messages with PADDING are intended to test the behavior
of UDP fragments, they are an exception to the usual rule that STUN
messages be less than the MTU of the path.The IAB has studied the problem of ``Unilateral Self Address
Fixing'', which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism RFC 3424. The STUN NAT Behavior Discovery usage
is an example of a protocol that performs this type of function. The IAB
has mandated that any protocols developed for this purpose document a
specific set of considerations. This section meets those
requirements.From RFC 3424, any UNSAF proposal
must provide: Precise definition of a specific, limited-scope problem that is
to be solved with the UNSAF proposal. A short term fix should not
be generalized to solve other problems; this is why "short term
fixes usually aren't".The specific problem being solved by the STUN NAT Behavior
Discovery usage is for a client, which may be located behind a NAT of
any type, to determine the instantaneous characteristics of that NAT
in order to either diagnose the cause of problems experienced by that
or other applications or for an application to modify its behavior
based on the current behavior of the NAT and an appropriate
statistical model of the behavior required for the application to
succeed.From , any UNSAF proposal must
provide: Description of an exit strategy/transition plan. The better
short term fixes are the ones that will naturally see less and
less use as the appropriate technology is deployed.The STUN NAT Behavior Discovery usage does not itself provide an
exit strategy for v4 NATs. At the time of this writing, it appears
some sort of NAT will be necessary between v6 clients and v4 servers,
but this specification will not be necessary with those v6 to v4 NATs,
because the IETF is planning to adequately describe their operation.
This specification will be of no interest for v6 to v6
connectivity.From , any UNSAF proposal must
provide: Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition.The STUN NAT Behavior Discovery usage allows a client to determine
the current behavior of a NAT. This information can be quite useful to
a developer or network administrator outside of an application, and as
such can be used to diagnose the brittleness induced in another
application. When used within an application itself, STUN NAT Behavior
Discovery allows the application to adjust its behavior according to
the current behavior of the NAT. This draft is experimental because
the extent to which brittleness is introduced to an application
relying on the Behavior Discovery usage is unclear and must be
carefully evaluated by the designers of the protocol making use of it.
The experimental test for this protocol is essentially determining
whether an application can be made less brittle through the use of
behavior-discovery information than it would be if attempted to make
use of the network without any awareness of the NATs its traffic must
pass through.From , any UNSAF proposal must
provide: Identify requirements for longer term, sound technical
solutions -- contribute to the process of finding the right longer
term solution.As long as v4 NATs are present, means of adapting to their presence
will be required. As described above, well-behaved v6 to v4 NATs and
direct v6 to v6 connections will not require behavior
characterization.From , any UNSAF proposal must
provide: Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports.This usage provides a set of generic attributes that can be
assembled to test many types of NAT behavior. While tests for the most
commonly known NAT box behaviors are described, the BEHAVE mailing
list regularly has descriptions of new behaviors, some of which may
not be readily detected using the tests described herein. However, the
techniques described in this usage can be assembled in different
combinations to test NAT behaviors not now known or envisioned.This specification requests that IANA make additions to the "STUN
Attributes Registry" and "STUN Error Code Registry".This specification defines several new STUN attributes. This
section directs IANA to add these new protocol elements to the IANA
registry of STUN protocol elements.0x0003: CHANGE-REQUEST0x0027:
RESPONSE-PORT0x0026: PADDING0x8027: CACHE-TIMEOUT0x802b:
RESPONSE-ORIGIN0x802c: OTHER-ADDRESSThis specification defines the "stun-behavior" and "stun-behaviors"
SRV service names. "stun-behavior" may be used with SRV protocol
specifiers "udp" and "tcp". "stun-behaviors" may only be specified
with "tcp". Thus, the allowable SRV queries are:This usage inherits the security considerations of STUN. This usage adds several new attributes;
security considerations for those are detailed here.OTHER-ADDRESS does not permit any new attacks; it provides another
place where an attacker can impersonate a STUN server but it is not an
interesting attack. An attacker positioned where it can compromise the
Binding Response can completely hide the STUN server from the
client.Requests containing both RESPONSE-PORT and PADDING are rejected by
the server. This prevents an amplification attack which is targeted at the originating address.The only attack possible with the PADDING attribute is to have a
large padding length which could cause a server to allocate a large
amount of memory. As servers will ignore any padding length greater than
64k so the scope of this attack is limited. In general, servers should
not allocate more memory than the size of the received datagram. This
attack would only affect non-compliant implementations.RESPONSE-ORIGIN and RESPONSE-PORT do not provide
any additional attacks.The authors would like to thank the authors of the original STUN specification from which many
of the ideas, attributes, and description in this document originated.
Thanks to Dan Wing, Cullen Jennings, and Magnus Westerlund for detailed
comments.RFC-EDITOR: Please remove this entire Change Log section while
formatting this document for publication.Only OTHER-ADDRESS, CHANGE-ADDRESS, and XOR-RESPONSE-TARGET
support is optional; support for PADDING and SOURCE-ADDRESS is now
mandatoryPADDING is now a mandatory attributeOTHER-ADDRESS is returned in all binding responses if the
server has a second IP addressClarified that only servers with two IP addresses should have
an SRV entryRemoved support for backward compatibility with 3489 clients by
removing non-XOR forms of attributes. Language states that
backward compatibility with 3489 clients is SHOULD NOT.
Compatibility with 3489 servers is left unspecified.PADDING is mandatory and language has been changed to indicate
that if a server supports PADDING it must either actually provide
the padding or return an error (can't support it but refuse to do
it)Require both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS to be
returned to support detection of generic ALGsChanged proposed status to experimentalMade significant changes to the introduction and applicability
statements to reflect the experimental statusFixed the New Attributes and IANA considerations not listing
the same attribute numbers.Removed mandatory shared secret credentials in favor of the
option of rate limiting or credentials. Specified that credentials
must be obtained from the user or parent application.Made OTHER-ADDRESS and SOURCE-ADDRESS optional to address
compatibility with 3489bis clients. Renamed SOURCE-ADDRESS as
RESPONSE-ORIGIN to avoid conflicts with 3489.Renamed XOR-RESPONSE-ADDRESS to XOR-RESPONSE-TARGETAdded discussion of FINGERPRINT and ALTERNATE-SERVER for
compliance with 3489bis stun usage definition requirements.fix terminology for endpoint-independent, address-dependent,
and address and port-dependent from rfc4787define the ALG detection to apply to UDP and TCPfix >From typo in 9.5added exception to single MTU size restriction for PADDINGremoved OPEN ISSUE about CHANGE-REQUEST IANA registry based on
the belief that we need to list that definition here now that
3489bis is dropping it.moved semantics of PADDING usage into behavior sections rather
than attributes sectionremoved reference to SERVER attributeremoved Open Issues sectionUpdated IAB considerationsClarified that behavior may vary by port used as well as by
destination IP/particular STUN server, and therefore specified
that all tests should be performed using the port the application
will useAdded additional text on selecting random port/ensuring port
has been unused prior to starting filtering testsspecified limit to start rate of tests and that tests
retransmissions should not synchronizeadditional explanatory text for XOR-RESPONSE-TARGETadded SRV entry to IANA section and subdivided to match STUN
registries from 5389clarified that test combinations are non-normativeNumerous clarificationsChanged PADDING to default to interface MTU, and changed
maximum length to not make IP datagram exceed 64KAdded text that server should allocate TCP and TCP/TLSIn applicability section, add explicit requirement that citing
drafts must specify how they handle failureAdd new subsection on selecting the source port used for tests,
covering both requirements that the same port be used for tests as
for the application and dependencies on previous bindings.
Reference that section explicitly for tests that are sensitive to
previous binding state.Change SRV discovery to stun-behavior for UDP and TCP and
stun-behaviors for TLS/TCP.Add SRV registry subsection to IANA section.Reworked the applicability section and provided more detail in
the P2P application exampleAdditional clarification on the limits of the tests, and that
the described tests include only those utilizing a single source
IP, so can't test overloading.Several changes to clarify and make consistent security
requirements for XOR-RESPONSE-TARGETNumerous other clarifications in response to comments.Changed XOR-RESPONSE-ADDRESS to RESPONSE-PORT which resulted in
CACHE-TIMEOUT and XOR-REFLECTED-FROM. This resulted in a
simplification of the Security ConsiderationsFixed erroneous STUN expansionsClarification of when a fallback mechanism will be used.Numerous other clarifications in response to comments.