doc: Add RFC documents

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]
+