summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5780.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5780.txt')
-rw-r--r--doc/rfc/rfc5780.txt1515
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc5780.txt b/doc/rfc/rfc5780.txt
new file mode 100644
index 0000000..ce09509
--- /dev/null
+++ b/doc/rfc/rfc5780.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) D. MacDonald
+Request for Comments: 5780 B. Lowekamp
+Category: Experimental Skype
+ISSN: 2070-1721 May 2010
+
+
+NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
+
+Abstract
+
+ This specification defines an experimental usage of the Session
+ Traversal Utilities for NAT (STUN) Protocol that discovers the
+ presence and current behavior of NATs and firewalls between the STUN
+ client and the STUN server.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5780.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 1]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 2]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+Table of Contents
+
+ 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 6
+ 2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7
+ 2.3. Experimental Goals . . . . . . . . . . . . . . . . . . . . 8
+ 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 9
+ 3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10
+ 3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 10
+ 3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 10
+ 3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11
+ 3.5. Determining Fragment Handling . . . . . . . . . . . . . . 11
+ 3.6. Detecting a Generic Application Level Gateway (ALG) . . . 11
+ 4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 12
+ 4.2. Checking for UDP Connectivity with the STUN Server . . . . 13
+ 4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14
+ 4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 14
+ 4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15
+ 4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 15
+ 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
+ 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 18
+ 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 7.1. Representing Transport Addresses . . . . . . . . . . . . . 21
+ 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21
+ 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 21
+ 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22
+ 7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 22
+ 7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
+ 8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 23
+ 8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 23
+ 8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 24
+ 8.4. Requirements for a Long-Term Solution . . . . . . . . . . 24
+ 8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 24
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
+ 9.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 25
+ 9.2. Port Numbers and SRV Registry . . . . . . . . . . . . . . 25
+ 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
+ 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
+
+
+
+MacDonald & Lowekamp Experimental [Page 3]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+1. Applicability
+
+ 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 behavior 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
+ [RFC5245] and [RFC5626] for establishing communication channels when
+ a publicly accessible rendezvous service is available.
+
+ The uses envisioned for the STUN attributes included in this document
+ are diagnostics and real-time tuning of applications. For example,
+ determining what may work and should be tried first compared to more
+ expensive methods. The attributes can also be used to observe
+ behaviors that causes an application's communication to fail, thus
+ enabling better selection of methods of recovery. The STUN
+ attributes could also be a basis for a network technician's
+ diagnostics tool to observe NAT behavior.
+
+ This document 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 peer-to-peer (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. Consider a node that tries to join an
+ overlay as a full peer when its NAT prevents sufficient connectivity;
+ joining and withdrawing from the overlay might be expensive and/or
+ lead to unreliable or poorly performing operations. 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 2.2 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 RFC 3489 [RFC3489], now RFC 5389 [RFC5389]). This
+ specification acknowledges that the information gathered in this
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 4]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ 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 whereas RFC 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.
+
+ This STUN usage requires an application using it to have a fallback.
+ However, unlike ICE's focus on the problems inherent in VoIP
+ sessions, this STUN usage doesn't assume that it will be used to
+ establish a connection between a single pair of machines, so
+ alternative fallback mechanisms may be available.
+
+ 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 Track 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
+ aggressively the fallback mechanism is utilized, so there must be a
+ clear definition of when the fallback mechanism is invoked.
+
+1.1. Requirements Language
+
+ 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 [RFC2119].
+
+
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 5]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+2. Introduction
+
+ "Session Traversal Utilities for NAT (STUN)" [RFC5389] 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 behavior of the NAT/firewall (NAT/FW) 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
+ behavior under load and over time. Applications requiring high
+ reliability must be prepared for the NAT's behavior to become more
+ restrictive. Specifically, it has been found that under load NATs
+ may transition to the most restrictive filtering and mapping behavior
+ 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.
+
+2.1. Example Diagnostic Use
+
+ 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 that
+
+ o adding new traffic to new destinations (STUN servers) has the
+ potential to itself change the behavior of a NAT and
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 6]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ o the 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.
+
+2.2. Example Use with P2P Overlays
+
+ An application could use Behavior Discovery in a 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 or NATs offer 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 across the overlay,
+ which guarantees minimum response latency, but can waste bandwidth.)
+ Over time, A 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
+
+
+
+MacDonald & Lowekamp Experimental [Page 7]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ 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 or NATs change 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:
+
+ o Use of a protocol capable of offering reliable end-user
+ performance while using unreliable links between pairs of nodes.
+
+ o A protocol offering a reliable fallback to connections attempted
+ based on the results of Behavior Discovery probing.
+
+ o 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 document 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 behavior, 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.
+
+2.3. Experimental Goals
+
+ The criteria for an application to successfully demonstrate use of
+ the NAT Behavior Discovery STUN usage would include:
+
+ o 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.
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 8]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ o 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.
+
+ o 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.
+
+ o 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.
+
+3. Overview of Operations
+
+ 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 RFC 3489 [RFC3489] for either clients or servers.
+ Implementors of clients that wish to be compliant with RFC 3489
+ servers should see that specification. Implementors of servers
+ SHOULD NOT include support for RFC 3489 clients, as the original uses
+ of that protocol have been deprecated.
+
+ Because 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 5, 6,
+ and 7.
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 9]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+3.1. Determining NAT Mapping
+
+ A client behind a NAT wishes to determine if that NAT is currently
+ using Endpoint-Independent, Address-Dependent, or Address and Port-
+ Dependent Mapping [RFC4787]. The client performs a series of tests
+ that make use of the OTHER-ADDRESS attribute; these tests are
+ described in detail in Section 4. These tests send binding requests
+ to the alternate address and port of the STUN server to determine
+ mapping behavior. These tests can be used for UDP, TCP, or TCP/TLS
+ connections.
+
+3.2. Determining NAT Filtering
+
+ A client behind a NAT wishes to determine if that NAT is currently
+ using Endpoint-Independent, Address-Dependent, or Address and Port-
+ Dependent Filtering [RFC4787]. The client performs a series of tests
+ that make use of the OTHER-ADDRESS and CHANGE-REQUEST attributes;
+ these tests are described in Section 4. 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.
+
+3.3. Binding Lifetime Discovery
+
+ 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 discovery 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
+
+
+
+MacDonald & Lowekamp Experimental [Page 10]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ existing binding that hasn't had traffic sent on it is still open
+ after time T. This approach is described in detail in Section 4.6.
+ This test applies only to UDP datagrams.
+
+3.4. Diagnosing NAT Hairpinning
+
+ 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.
+
+3.5. Determining Fragment Handling
+
+ 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 that are most interesting to the application can be retested.
+ PADDING only applies to UDP datagrams. PADDING can not be used with
+ RESPONSE-PORT.
+
+3.6. Detecting a Generic Application Level Gateway (ALG)
+
+ A number of NAT boxes are now being deployed into the market that 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.
+
+4. Discovery Process
+
+ This section provides a descriptive overview of how the NAT Behavior
+ Discovery usage primitives allow checks to be made to discover the
+ current behavior of the NAT or NATs an application is behind. These
+ tests can only give the instantaneous behavior of a NAT; it has been
+ found that NATs can change behavior under load and over time. The
+
+
+
+MacDonald & Lowekamp Experimental [Page 11]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ results of these tests therefore can be regarded as upper bounds --
+ an application must assume that NAT behavior 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 Section 4.1.
+
+ Definitions for NAT filtering and mapping behavior are from
+ [RFC4787]. The tests described here are for UDP connectivity, NAT
+ mapping behavior, NAT filtering behavior, 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.
+
+4.1. Source Port Selection
+
+ Proper source port selection is important to ensuring the usefulness
+ and accuracy of the Behavior Discovery tests. There are two
+ preconditions for tests:
+
+ o 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.
+
+ o 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:
+
+
+
+MacDonald & Lowekamp Experimental [Page 12]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ o 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.
+
+ o 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.
+
+ o 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 sensitive to prior state on a NAT will be
+ indicated below.
+
+4.2. Checking for UDP Connectivity with the STUN Server
+
+ 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 [RFC5389] functionality.
+
+
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 13]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+4.3. Determining NAT Mapping Behavior
+
+ 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.
+
+4.4. Determining NAT Filtering Behavior
+
+ 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 behavior 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 behavior is Address-
+ Dependent Filtering; if no response is received, the current behavior
+ is Address and Port-Dependent Filtering.
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 14]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+4.5. Combining and Ordering Tests
+
+ 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 Section 4.3. An application that
+ determines its NAT does not always provide Endpoint-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 [RFC5245],
+ 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. Section 5 restricts the rate at which clients may begin
+ new STUN transactions.
+
+4.6. Binding Lifetime Discovery
+
+ 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 more quickly under heavy load or might not
+ behave as the tests suggest. For this reason, applications that
+ require reliable bindings must send keepalives as frequently as
+ required by all NAT devices that will be encountered. Suggested
+ refresh intervals are outside the scope of this document. [RFC5245]
+ and OUTBOUND [RFC5626] 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.
+
+
+
+MacDonald & Lowekamp Experimental [Page 15]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ 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 that 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
+
+
+
+MacDonald & Lowekamp Experimental [Page 16]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ 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
+ [RFC5626] 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.
+
+5. Client Behavior
+
+ Unless otherwise specified here, all procedures for preparing,
+ sending, and processing messages as described in the STUN Binding
+ Usage [RFC5389] 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 retransmission timeouts
+ (RTOs) do not synchronize the retransmissions of each transaction.
+
+5.1. Discovery
+
+ 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
+
+
+
+MacDonald & Lowekamp Experimental [Page 17]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ the STUN servers. The domain is resolved to a transport address
+ using SRV procedures [RFC2782]. 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 [RFC5389].
+
+5.2. Security
+
+ 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
+ [RFC5389].
+
+6. Server Behavior
+
+ Unless otherwise specified here, all procedures for preparing,
+ sending, and processing messages as described for the STUN Binding
+ Usage of STUN [RFC5389] 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".
+
+6.1. Preparing the Response
+
+ After performing all authentication and verification steps, the
+ server begins processing specific to this Usage if the Binding
+ Request contains any request attributes defined in this document:
+
+
+
+MacDonald & Lowekamp Experimental [Page 18]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ RESPONSE-PORT, CHANGE-REQUEST, or PADDING. If the Binding Request
+ does not contain any attributes from this document, OTHER-ADDRESS and
+ RESPONSE-ORIGIN are still included in the Binding Response.
+
+ The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in
+ its Response.
+
+ If the Request contains the 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 on
+ which the Binding Request was received; this is summarized in
+ Table 1.
+
+ 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 the 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.
+
+ +--------------------+----------------+-------------+---------------+
+ | Flags | Source Address | Source Port | OTHER-ADDRESS |
+ +--------------------+----------------+-------------+---------------+
+ | none | Da | Dp | Ca:Cp |
+ | Change IP | Ca | Dp | Ca:Cp |
+ | Change port | Da | Cp | Ca:Cp |
+ | Change IP and | Ca | Cp | Ca:Cp |
+ | Change port | | | |
+ +--------------------+----------------+-------------+---------------+
+
+ Table 1: Impact of Flags on Packet Source and OTHER-ADDRESS
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 19]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ The 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 Table 1, 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 [RFC5389]. 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 source address of the Request.
+ If RESPONSE-PORT is present, the server sends the response to that
+ port instead of the originating port.
+
+7. New Attributes
+
+ 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 RFC 3489 [RFC3489] but is redefined here as
+ that document is obsoleted by [RFC5389].
+
+ Comprehension-required range (0x0000-0x7FFF):
+ 0x0003: CHANGE-REQUEST
+ 0x0026: PADDING
+ 0x0027: RESPONSE-PORT
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 20]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ Comprehension-optional range (0x8000-0xFFFF):
+ 0x802b: RESPONSE-ORIGIN
+ 0x802c: OTHER-ADDRESS
+
+7.1. Representing Transport Addresses
+
+ 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 [RFC5389].
+
+7.2. CHANGE-REQUEST
+
+ The CHANGE-REQUEST attribute contains two flags to control the IP
+ address and port that 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:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The meanings of the flags are:
+
+ A: 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.
+
+ B: 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.
+
+7.3. RESPONSE-ORIGIN
+
+ 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.
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 21]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+7.4. OTHER-ADDRESS
+
+ 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
+ RFC 3489 [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.
+
+7.5. RESPONSE-PORT
+
+ The RESPONSE-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 transmitted
+ to the source IP address of the Binding Request and the port
+ contained in RESPONSE-PORT. It is used in tests such as Section 4.6.
+ 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.
+
+7.6. PADDING
+
+ 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 free-form 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.
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 22]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+8. IAB Considerations
+
+ The IAB has studied the problem of "Unilateral Self-Address Fixing"
+ (UNSAF), 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 [RFC3424]. 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.
+
+8.1. Problem Definition
+
+ From RFC 3424 [RFC3424], 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. Such generalizations lead to
+ the prolonged dependence on and usage of the supposed short term
+ fix -- meaning that it is no longer accurate to call it "short
+ term".
+
+ 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. This
+ determination allows either the diagnosis of the cause of problems
+ experienced by that or other applications or the modification of an
+ application's behavior based on the current behavior of the NAT and
+ an appropriate statistical model of the behavior required for the
+ application to succeed.
+
+8.2. Exit Strategy
+
+ From [RFC3424], 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.
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 23]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+8.3. Brittleness Introduced by STUN NAT Behavior Discovery
+
+ From [RFC3424], 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 document 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.
+
+8.4. Requirements for a Long-Term Solution
+
+ From [RFC3424], 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.
+
+8.5. Issues with Existing NAPT Boxes
+
+ From [RFC3424], any UNSAF proposal must provide:
+
+ Discussion of the impact of the noted practical issues with
+ existing deployed NATs 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
+
+
+
+MacDonald & Lowekamp Experimental [Page 24]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ 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.
+
+9. IANA Considerations
+
+9.1. STUN Attribute Registry
+
+ This specification defines several new STUN attributes. IANA has
+ added these new protocol elements to the "STUN Attributes" registry.
+
+ 0x0003: CHANGE-REQUEST
+ 0x0027: RESPONSE-PORT
+ 0x0026: PADDING
+ 0x8027: CACHE-TIMEOUT
+ 0x802b: RESPONSE-ORIGIN
+ 0x802c: OTHER-ADDRESS
+
+9.2. Port Numbers and SRV Registry
+
+ By default, the STUN NAT Behavior Discovery usage runs on the same
+ ports as STUN: 3478 over UDP and TCP, and 5349 for TCP over TLS.
+ However, the Behavior Discovery usage has its own set of Service
+ Record (SRV) names: "stun-behavior" for UDP and TCP, and "stun-
+ behaviors" for TLS. Either the SRV procedures or the ALTERNATE-
+ SERVER procedures, subject to the recommendations of Section 5, can
+ be used to run Behavior Discovery on a different port.
+
+ This 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:
+
+ _stun-behavior._udp UDP
+ _stun-behavior._tcp TCP
+ _stun-behaviors._tcp TLS over TCP
+
+10. Security Considerations
+
+ This usage inherits the security considerations of STUN [RFC5389].
+ This usage adds several new attributes; security considerations for
+ those are detailed here.
+
+
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 25]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+ 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.
+
+ o Requests containing both RESPONSE-PORT and PADDING are rejected by
+ the server. This prevents an amplification attack that is
+ targeted at the originating address.
+
+ The only attack possible with the PADDING attribute is to have a
+ large padding length that 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.
+
+11. Acknowledgements
+
+ The authors would like to thank the authors of the original STUN
+ specification [RFC3489] 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.
+
+12. References
+
+12.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
+ (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+ RFC 4787, January 2007.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+ October 2008.
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 26]
+
+RFC 5780 NAT Behavior Discovery May 2010
+
+
+12.2. Informative References
+
+ [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
+ Self-Address Fixing (UNSAF) Across Network Address
+ Translation", RFC 3424, November 2002.
+
+ [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
+ "STUN - Simple Traversal of User Datagram Protocol (UDP)
+ Through Network Address Translators (NATs)", RFC 3489,
+ March 2003.
+
+ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols", RFC 5245,
+ April 2010.
+
+ [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
+ Initiated Connections in the Session Initiation Protocol
+ (SIP)", RFC 5626, October 2009.
+
+Authors' Addresses
+
+ Derek C. MacDonald
+ Skype
+ Palo Alto, CA
+ USA
+
+ EMail: derek.macdonald@gmail.com
+
+
+ Bruce B. Lowekamp
+ Skype
+ Palo Alto, CA
+ USA
+
+ EMail: bbl@lowekamp.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+MacDonald & Lowekamp Experimental [Page 27]
+