draft-ietf-behave-nat-behavior-discovery-08.txt   rfc5780.txt 
BEHAVE D. MacDonald Internet Engineering Task Force (IETF) D. MacDonald
Internet-Draft CounterPath Solutions, Inc. Request for Comments: 5780 B. Lowekamp
Intended status: Experimental B. Lowekamp Category: Experimental Skype
Expires: March 31, 2010 MYMIC LLC ISSN: 2070-1721 May 2010
September 27, 2009
NAT Behavior Discovery Using STUN
draft-ietf-behave-nat-behavior-discovery-08
Status of this Memo NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering This specification defines an experimental usage of the Session
Task Force (IETF), its areas, and its working groups. Note that Traversal Utilities for NAT (STUN) Protocol that discovers the
other groups may also distribute working documents as Internet- presence and current behavior of NATs and firewalls between the STUN
Drafts. client and the STUN server.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for examination, experimental implementation, and
evaluation.
The list of Internet-Draft Shadow Directories can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. 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.
This Internet-Draft will expire on March 31, 2010. 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.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This specification defines an experimental usage of the Session described in the Simplified BSD License.
Traversal Utilities for NAT (STUN) Protocol that discovers the
presence and current behaviour of NATs and firewalls between the STUN
client and the STUN server.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in RFC 2119 [RFC2119]. 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.
Table of Contents Table of Contents
1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 7 2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 6
2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7 2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7
2.3. Experimental Success . . . . . . . . . . . . . . . . . . . 9 2.3. Experimental Goals . . . . . . . . . . . . . . . . . . . . 8
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 10 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 9
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10 3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 11 3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 10
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11 3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 10
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11 3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 12 3.5. Determining Fragment Handling . . . . . . . . . . . . . . 11
3.6. Detecting a Generic Application Level Gateways (ALG) . . . 12 3.6. Detecting a Generic Application Level Gateway (ALG) . . . 11
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 12 4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 13 4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 12
4.2. Checking for UDP Connectivity with the STUN Server . . . . 14 4.2. Checking for UDP Connectivity with the STUN Server . . . . 13
4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14 4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14
4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 15 4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 14
4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15 4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15
4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 16 4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 15
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 19 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 18
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 21 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Representing Transport Addresses . . . . . . . . . . . . . 21 7.1. Representing Transport Addresses . . . . . . . . . . . . . 21
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 22 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 22 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 21
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22
7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 23 7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 22
7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 24 8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 23
8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 24 8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 24
8.4. Requirements for a Long Term Solution . . . . . . . . . . 25 8.4. Requirements for a Long-Term Solution . . . . . . . . . . 24
8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 25 8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 25 9.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 25
9.2. SRV Registry . . . . . . . . . . . . . . . . . . . . . . . 26 9.2. Port Numbers and SRV Registry . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 28
A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 28
A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 28
A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 29
A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 29
A.6. from draft-ietf-behave-nat-behavior-discovery-04 . . . . . 29
A.7. from draft-ietf-behave-nat-behavior-discovery-05 . . . . . 30
A.8. from draft-ietf-behave-nat-behavior-discovery-06 . . . . . 30
A.9. from draft-ietf-behave-nat-behavior-discovery-07 . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Applicability 1. Applicability
This experimental NAT Behavior Discovery STUN usage provides This experimental NAT Behavior Discovery STUN usage provides
information about a NAT device's observable transient behavior; it information about a NAT device's observable transient behavior; it
determines a NAT's behavior with regard to the STUN server used and 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. 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 This STUN usage does not allow an application behind a NAT to make an
absolute determination of the NAT's characteristics. NAT devices do absolute determination of the NAT's characteristics. NAT devices do
not behave consistently enough to predict future behaviour with any not behave consistently enough to predict future behavior with any
guarantee. Applications requiring reliable reach between two guarantee. Applications requiring reliable reach between two
particular endpoints must establish a communication channel through particular endpoints must establish a communication channel through
NAT using another technique. IETF has proposed standards including NAT using another technique. IETF has proposed standards including
ICE [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for [RFC5245] and [RFC5626] for establishing communication channels when
establishing communication channels when a publicly accessible a publicly accessible rendezvous service is available.
rendezvous service is available.
The primary uses envisioned for the STUN attributes included in this The uses envisioned for the STUN attributes included in this document
draft are diagnostics and real-time tuning of applications. The are diagnostics and real-time tuning of applications. For example,
techniques possible with this usage are powerful diagnostic tools in determining what may work and should be tried first compared to more
the hands of a network administrator or system programmer trying to expensive methods. The attributes can also be used to observe
determine the causes of network failure; particularly when behavior behaviors that causes an application's communication to fail, thus
varies by load, destination, or other factors that may be related to enabling better selection of methods of recovery. The STUN
NAT behavior. attributes could also be a basis for a network technician's
diagnostics tool to observe NAT behavior.
This draft also proposes experimental usage of these attributes for This document proposes experimental usage of these attributes for
real-time optimization of parameters for protocols in situations real-time optimization of parameters for protocols in situations
where a publicly accessible rendezvous service is not available. where a publicly accessible rendezvous service is not available.
Such a use of these techniques is only possible when the results are Such a use of these techniques is only possible when the results are
applied as an optimization and a reliable fallback is available in applied as an optimization and a reliable fallback is available in
case the NAT's behavior becomes more restrictive than determined by case the NAT's behavior becomes more restrictive than determined by
the Behavior Discovery tests. One possible application is role the Behavior Discovery tests. One possible application is role
selection in P2P networks based on statistical experience with selection in peer-to-peer (P2P) networks based on statistical
establishing direct connections and diagnosing NAT behavior with a experience with establishing direct connections and diagnosing NAT
variety of peers. The experimental question is whether such a test behavior with a variety of peers. The experimental question is
is useful. If a node trying to join an overlay as a full peer when whether such a test is useful. Consider a node that tries to join an
its NAT prevents sufficient connectivity and then withdrawing is overlay as a full peer when its NAT prevents sufficient connectivity;
expensive or leads to unreliable or poorly performing operation, then joining and withdrawing from the overlay might be expensive and/or
even if the behavior discovery check is only "correct" 75% of the lead to unreliable or poorly performing operations. Even if the
time, its relative cheapness may make it very useful for optimizing behavior discovery check is only "correct" 75% of the time, its
the behavior of the overlay network. Section 2.2 describes this 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 experimental application in more detail and discusses how to evaluate
its success or failure. its success or failure.
The applications of this STUN usage differ from the original use of The applications of this STUN usage differ from the original use of
STUN (originally RFC3489 [RFC3489], now RFC5389 [RFC3489]). This STUN (originally RFC 3489 [RFC3489], now RFC 5389 [RFC5389]). This
specification acknowledges that the information gathered in this specification acknowledges that the information gathered in this
usage is not, and cannot be, correct 100% of the time, whereas STUN 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 focused only on getting information that could be known to be correct
and static. and static.
This specification can also be compared to ICE. ICE requires a This specification can also be compared to ICE. ICE requires a
fallback to TURN be available wheras 3489-based applications tried to fallback to TURN be available whereas RFC 3489 based applications
determine in advance whether they would need a relay and what their tried to determine in advance whether they would need a relay and
peer reflexive address will be, which is not generally achievable. what their peer reflexive address will be, which is not generally
be, which are both impossible. This STUN usage requires an achievable.
application using it to have a fallback, but unlike ICE's focus on
the problems inherent in VoIP sessions, doesn't assume that it will This STUN usage requires an application using it to have a fallback.
only be used to establish a connection between a single pair of However, unlike ICE's focus on the problems inherent in VoIP
machines, and so alternative fallback mechanisms may make sense. For sessions, this STUN usage doesn't assume that it will be used to
example, in a P2P application it may be possible to simply switch out establish a connection between a single pair of machines, so
of the role where such connections need to be established or to 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 select an alternative indirect route if the peer discovers that, in
practice, 10% of its connection attempts fail. practice, 10% of its connection attempts fail.
It is submitted to the Internet community as an experimental protocol It is submitted to the Internet community as an experimental protocol
that, when applied with appropriate statistical underpinnings and that, when applied with appropriate statistical underpinnings and
application behavior that is ultimately based on experienced application behavior that is ultimately based on experienced
connectivity patterns, can lead to more stability and increased connectivity patterns, can lead to more stability and increased
performance than is available without the knowledge it provides. performance than is available without the knowledge it provides.
If a standards document specifies the use of any portion of this STUN If a Standards Track document specifies the use of any portion of
usage, that document MUST describe how incorrect information derived this STUN usage, that document MUST describe how incorrect
using these methods will be managed, either through identifying when information derived using these methods will be managed, either
a NAT's behavior changed or because the protocol uses such knowledge through identifying when a NAT's behavior changed or because the
as an optimization but remains functional when the NAT's behavior protocol uses such knowledge as an optimization but remains
changes. The referencing document MUST also define when the fallback functional when the NAT's behavior changes. The referencing document
mechanism will be invoked. Applications in different domains may MUST also define when the fallback mechanism will be invoked.
vary greatly in how agressively the fallback mechanism is utilized, Applications in different domains may vary greatly in how
so there must be a clear defintion of when the fallback mechanism is aggressively the fallback mechanism is utilized, so there must be a
invoked. 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].
2. Introduction 2. Introduction
The Session Traversal Utilities for NAT (STUN) [RFC5389] provides a "Session Traversal Utilities for NAT (STUN)" [RFC5389] provides a
mechanism to discover the reflexive transport address toward the STUN mechanism to discover the reflexive transport address toward the STUN
server, using the Binding Request. This specification defines the server, using the Binding Request. This specification defines the
NAT Behavior Discovery STUN usage, which allows a STUN client to NAT Behavior Discovery STUN usage, which allows a STUN client to
probe the current behaviour of the NAT/Firewall devices between the probe the current behavior of the NAT/firewall (NAT/FW) devices
client and the STUN server. This usage defines new STUN attributes between the client and the STUN server. This usage defines new STUN
for the Binding Request and Binding Response. attributes for the Binding Request and Binding Response.
Many NAT/FW devices do not behave consistently and will change their Many NAT/FW devices do not behave consistently and will change their
behaviour under load and over time. Applications requiring high behavior under load and over time. Applications requiring high
reliability must be prepared for the NAT's behaviour to become more reliability must be prepared for the NAT's behavior to become more
restrictive. Specifically, it has been found that under load NATs restrictive. Specifically, it has been found that under load NATs
may transition to the most restrictive filtering and mapping may transition to the most restrictive filtering and mapping behavior
behaviour and shorten the lifetime of new and existing bindings. In and shorten the lifetime of new and existing bindings. In short,
short, applications can discover how bad things currently are, but applications can discover how bad things currently are, but not how
not how bad things will get. bad things will get.
Despite this limitation, instantaneous observations are often quite Despite this limitation, instantaneous observations are often quite
useful in troubleshooting network problems, and repeated tests over useful in troubleshooting network problems, and repeated tests over
time, or in known load situations, may be used to characterize a time, or in known load situations, may be used to characterize a
NAT's behavior. In particular, in the hands of a person NAT's behavior. In particular, in the hands of a person
knowledgeable about the needs of an application and the nodes an knowledgeable about the needs of an application and the nodes an
application needs to communicate with, it can be a powerful tool. application needs to communicate with, it can be a powerful tool.
2.1. Example Diagnostic Use 2.1. Example Diagnostic Use
Applications that work well in the lab, but fail in a deployment, are Applications that work well in the lab, but fail in a deployment, are
notoriously common within distributed systems. There are few systems notoriously common within distributed systems. There are few systems
developers who have not had the experience of searching to determine developers who have not had the experience of searching to determine
the difference in the environments for insight as to what real- the difference in the environments for insight as to what real-
network behavior was missed in the testing lab. The behavior network behavior was missed in the testing lab. The Behavior
discovery usage offers a powerful tool that can be used to check NAT Discovery usage offers a powerful tool that can be used to check NAT
and firewall behavior as the application is running. For example, an and firewall behavior as the application is running. For example, an
application could be designed to perform Behavior Discovery tests application could be designed to perform Behavior Discovery tests
whenever it experiences significant communications problems when whenever it experiences significant communications problems when
running. Such analysis might be included as part of the diagnostic running. Such analysis might be included as part of the diagnostic
information logged by the application. information logged by the application.
As they are being used to detect instantaneous behavior for analysis As they are being used to detect instantaneous behavior for analysis
by an experienced developer or administrator, there are relatively by an experienced developer or administrator, there are relatively
few concerns about this application of the NAT Behavior Discovery few concerns about this application of the NAT Behavior Discovery
STUN usage. However, the user should be aware that STUN usage. However, the user should be aware that
skipping to change at page 7, line 46 skipping to change at page 7, line 13
potential to itself change the behavior of a NAT and potential to itself change the behavior of a NAT and
o the user must be careful to select a STUN server that is o the user must be careful to select a STUN server that is
appropriately located, ideally collocated (or even integrated) appropriately located, ideally collocated (or even integrated)
with the communication partners of the application in question, with the communication partners of the application in question,
for the results to be applicable to the network conditions for the results to be applicable to the network conditions
experienced by the application. experienced by the application.
2.2. Example Use with P2P Overlays 2.2. Example Use with P2P Overlays
An application could use Behavior Discovery in a Peer-to-Peer (P2P) An application could use Behavior Discovery in a P2P protocol to
protocol to determine if a particular endpoint is a reasonable determine if a particular endpoint is a reasonable candidate to
candidate to participate as a peer or supernode (defined here as a participate as a peer or supernode (defined here as a peer in the
peer in the overlay that offers services, including message routing, overlay that offers services, including message routing, to other
to other members or clients of the overlay network). This P2P members or clients of the overlay network). This P2P network
network application is willing to select supernodes that might be application is willing to select supernodes that might be located
located behind NATs to avoid the cost of dedicated servers. A behind NATs to avoid the cost of dedicated servers. A supernode
supernode candidate requires that its NAT(s) offer(s) Endpoint- candidate requires that its NAT or NATs offer Endpoint-Independent
Independent Filtering. It might periodically re-run tests and would Filtering. It might periodically re-run tests and would remove
remove itself as a supernode if its NAT/FW chain lost this itself as a supernode if its NAT/FW chain lost this characteristic.
characteristic. These tests could be run with other supernodes These tests could be run with other supernodes acting as STUN servers
acting as STUN servers as well as with dedicated STUN servers. As as well as with dedicated STUN servers. As many P2P algorithms
many P2P algorithms tolerate non-transitive connectivity between a tolerate non-transitive connectivity between a portion of their
portion of their peers, guaranteed pair-wise reliable reach might be peers, guaranteed pair-wise reliable reach might be sacrificed in
sacrificed in order to distribute the P2P overlay's load across peers order to distribute the P2P overlay's load across peers that can be
that can be directly contacted by the majority of users. directly contacted by the majority of users.
Consider an example from a hypothetical P2P protocol in more detail: 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 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 peers already in the overlay. If the results of its testing indicate
A is behind a "good" NAT (with endpoint-independent mapping and A is behind a "good" NAT (with Endpoint-Independent Mapping and
filtering), A will join the overlay and establish connections with Filtering), A will join the overlay and establish connections with
appropriate peers in the overlay to join the overlay's topology. appropriate peers in the overlay to join the overlay's topology.
Although A is reachable by routing messages across the overlay Although A is reachable by routing messages across the overlay
topology, A will also include in its communication with other nodes topology, A will also include in its communication with other nodes
that they may reach it directly using its reflexive IP address (or that they may reach it directly using its reflexive IP address (or
addresses) that A discovered in its initial testing. Suppose that 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 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 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 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 a certain amount of time, then it routes the message to A across the
overlay instead and includes a flag that indicates a direct overlay instead and includes a flag that indicates a direct
connection was attempted but failed. (Alternatively, B could connection was attempted but failed. (Alternatively, B could
simultaneously send the message to A's IP address and across the simultaneously send the message to A's IP address across the overlay,
overlay, which guarantees minimum response latency, but can waste which guarantees minimum response latency, but can waste bandwidth.)
bandwidth.) A over time observes the percentage of successful direct Over time, A observes the percentage of successful direct messages it
messages it receives out of those attempted. If the percentage of receives out of those attempted. If the percentage of successful
successful direct connections is below some threshold (perhaps 75%), direct connections is below some threshold (perhaps 75%), then A may
then A may stop advertising for direct connections because it has stop advertising for direct connections because it has determined in
determined in practice that its NATs are not providing sufficiently practice that its NATs are not providing sufficiently reliable
reliable connectivity to justify the cost of attempting the direct connectivity to justify the cost of attempting the direct message.
message. But if the percentage is high enough, A continues to But if the percentage is high enough, A continues to advertise
advertise because the successful direct connections are improving the because the successful direct connections are improving the overlay's
overlay's performance by reducing the routing load imposed on the performance by reducing the routing load imposed on the overlay. If
overlay. If at some point, A's NAT(s) changes behavior, A will at some point, A's NAT or NATs change behavior, A will notice a
notice a change in its percentage of successful direct connections change in its percentage of successful direct connections and may re-
and may re-evaluate its decision to advertise a public address. In evaluate its decision to advertise a public address. In this
this hypothetical example, Behavior Discovery is used for A's initial hypothetical example, behavior discovery is used for A's initial
operating mode selection, but the actual decision for whether to operating mode selection, but the actual decision for whether to
continue advertising that public IP/port pair is made based on actual continue advertising that public IP/port pair is made based on actual
operating data. The results of the behavior-discovery usage are also operating data. The results of the Behavior Discovery usage are also
used as a performance optimization, as A is at all times able to used as a performance optimization, as A is at all times able to
establish connectivity through the overlay if the attempted direct establish connectivity through the overlay if the attempted direct
connection fails. connection fails.
Use of Behavior Discovery for such an application requires: Use of behavior discovery for such an application requires:
o Use of a protocol capable of offering reliable end-user o Use of a protocol capable of offering reliable end-user
performance using unreliable links between peers. performance while using unreliable links between pairs of nodes.
o A protocol offering a reliable fallback to connections attempted o A protocol offering a reliable fallback to connections attempted
based on the results of Behavior Discovery probing. based on the results of Behavior Discovery probing.
o The application is deployed behind NATs that provide Endpoint- o The application is deployed behind NATs that provide Endpoint-
Independent Filtering and that remain in this mode for an amount Independent Filtering and that remain in this mode for an amount
of time sufficient for the application to identify their behavior, of time sufficient for the application to identify their behavior,
distribute this information to the rest of the overlay, and distribute this information to the rest of the overlay, and
provide useful work for the application. provide useful work for the application.
This draft is experimental as applications implementing open This document is experimental as applications implementing open
protocols have yet to be deployed in such environments to demonstrate protocols have yet to be deployed in such environments to demonstrate
that these three requirements have been met. However, anecdotal that these three requirements have been met. However, anecdotal
evidence suggests that NATs targeted at households and small evidence suggests that NATs targeted at households and small
businesses have stable behaviour, especially when there are few businesses have stable behavior, especially when there are few
clients behind them. Numerous P2P applications have been deployed clients behind them. Numerous P2P applications have been deployed
that appear to have these properties, although their protocols have that appear to have these properties, although their protocols have
not yet been subjected to rigorous evaluation by standards bodies. not yet been subjected to rigorous evaluation by standards bodies.
2.3. Experimental Success 2.3. Experimental Goals
The criteria for an application to successfully demonstrate use of The criteria for an application to successfully demonstrate use of
the NAT Behavior Discovery STUN usage would include: the NAT Behavior Discovery STUN usage would include:
o An implementation that relies on this usage to determine its run- o An implementation that relies on this usage to determine its run-
time behavior, most likely using it to determine an initial choice time behavior, most likely using it to determine an initial choice
of options that are then adjusted based on experience with its of options that are then adjusted based on experience with its
network connections. network connections.
o The implementation must either demonstrate its applicability in o The implementation must either demonstrate its applicability in
skipping to change at page 10, line 19 skipping to change at page 9, line 33
for this usage, but others applications are possible as well. for this usage, but others applications are possible as well.
3. Overview of Operations 3. Overview of Operations
In a typical configuration, a STUN client is connected to a private In a typical configuration, a STUN client is connected to a private
network and through one or more NATs to the public Internet. The 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 client is configured with the address of a STUN server on the public
Internet. The Behavior Discovery usage makes use of SRV records so Internet. The Behavior Discovery usage makes use of SRV records so
that a server may use a different transport address for this usage that a server may use a different transport address for this usage
than for other usages. This usage does not provide backward than for other usages. This usage does not provide backward
compatibility with RFC3489 [RFC3489] for either clients or servers. compatibility with RFC 3489 [RFC3489] for either clients or servers.
Implementors of clients that wish to be compliant with RFC3489 Implementors of clients that wish to be compliant with RFC 3489
servers should see that specification. Implementors of servers servers should see that specification. Implementors of servers
SHOULD NOT include support for RFC3489 clients as the original uses SHOULD NOT include support for RFC 3489 clients, as the original uses
of that protocol have been deprecated. of that protocol have been deprecated.
Because the STUN forbids a server from creating a new TCP or TCP/TLS Because STUN forbids a server from creating a new TCP or TCP/TLS
connection to the client, many tests apply only to UDP. The connection to the client, many tests apply only to UDP. The
applicability of the various tests is indicated below. applicability of the various tests is indicated below.
The STUN NAT Behavior Discovery usage defines new attributes on the The STUN NAT Behavior Discovery usage defines new attributes on the
STUN Binding Request and STUN Binding Response that allow these STUN Binding Request and STUN Binding Response that allow these
messages to be used to diagnose the current behavior of the NAT(s) messages to be used to diagnose the current behavior of the NAT(s)
between the client and server. between the client and server.
This section provides a descriptive overview of the typical use of This section provides a descriptive overview of the typical use of
these attributes. Normative behavior is described in Sections 5, 6 these attributes. Normative behavior is described in Sections 5, 6,
and 7. and 7.
3.1. Determining NAT Mapping 3.1. Determining NAT Mapping
A client behind a NAT wishes to determine if the NAT it is behind is A client behind a NAT wishes to determine if that NAT is currently
currently using endpoint-independent, address-dependent, or address using Endpoint-Independent, Address-Dependent, or Address and Port-
and port-dependent mapping[RFC4787]. The client performs a series of Dependent Mapping [RFC4787]. The client performs a series of tests
tests that make use of the OTHER-ADDRESS attribute; these tests are that make use of the OTHER-ADDRESS attribute; these tests are
described in detail in Section 4. These tests send binding requests described in detail in Section 4. These tests send binding requests
to the alternate address and port of the STUN server to determine to the alternate address and port of the STUN server to determine
mapping behaviour. These tests can be used for UDP, TCP, or TCP/TLS mapping behavior. These tests can be used for UDP, TCP, or TCP/TLS
connections. connections.
3.2. Determining NAT Filtering 3.2. Determining NAT Filtering
A client behind a NAT wishes to determine if the NAT it is behind is A client behind a NAT wishes to determine if that NAT is currently
currently using endpoint-independent, address-dependent, or address using Endpoint-Independent, Address-Dependent, or Address and Port-
and port-dependent filtering[RFC4787]. The client performs a series Dependent Filtering [RFC4787]. The client performs a series of tests
of tests that make use of the OTHER-ADDRESS and CHANGE-REQUEST that make use of the OTHER-ADDRESS and CHANGE-REQUEST attributes;
attributes; these tests are described in Section 4. These tests these tests are described in Section 4. These tests request
request responses from the alternate address and port of the STUN responses from the alternate address and port of the STUN server; a
server; a precondition to these tests is that no binding be precondition to these tests is that no binding be established to the
established to the alternate address and port. See below for more alternate address and port. See below for more information. Because
information. Because the NAT does not know that the alternate the NAT does not know that the alternate address and port belong to
address and port belong to the same server as the primary address and the same server as the primary address and port, it treats these
port, it treats these responses the same as it would those from any responses the same as it would those from any other host on the
other host on the Internet. Therefore, the success of the binding Internet. Therefore, the success of the binding responses sent from
responses sent from the alternate address and port indicate whether the alternate address and port indicate whether the NAT is currently
the NAT is currently performing endpoint-independent filtering, performing Endpoint-Independent Filtering, Address-Dependent
address-dependent filtering, or address and port-dependent filtering. Filtering, or Address and Port-Dependent Filtering. This test
This test applies only to UDP datagrams. applies only to UDP datagrams.
3.3. Binding Lifetime Discovery 3.3. Binding Lifetime Discovery
Many systems, such as VoIP, rely on being able to keep a connection 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. open between a client and server or between peers of a P2P system.
Because NAT bindings expire over time, keepalive messages must be Because NAT bindings expire over time, keepalive messages must be
sent across the connection to preserve it. Because keepalives impose sent across the connection to preserve it. Because keepalives impose
some overhead on the network and servers, reducing the frequency of some overhead on the network and servers, reducing the frequency of
keepalives can be useful. keepalives can be useful.
A normal request-response protocol cannot be used to test binding A normal request-response protocol cannot be used to test binding
lifetime because the initial request resets the binding timer. lifetime because the initial request resets the binding timer.
Behavior Discover defines the RESPONSE-PORT attribute to allow the 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 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 client that is used to test the binding lifetime of a different port
allocated on the client. More generally, RESPONSE-PORT allows the allocated on the client. More generally, RESPONSE-PORT allows the
client to allocate two ports and request that responses to queries client to allocate two ports and request that responses to queries
sent from one port be delivered to the other. The client uses its 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 second port and the STUN server's alternate address to check if an
existing binding that hasn't had traffic sent on it is still open 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. after time T. This approach is described in detail in Section 4.6.
This test applies only to UDP datagrams. This test applies only to UDP datagrams.
3.4. Diagnosing NAT Hairpinning 3.4. Diagnosing NAT Hairpinning
STUN Binding Requests allow a client to determine whether it is STUN Binding Requests allow a client to determine whether it is
behind a NAT that supports hairpinning of connections. To perform behind a NAT that supports hairpinning of connections. To perform
this test, the client first sends a Binding Request to its STUN this test, the client first sends a Binding Request to its STUN
server to determine its mapped address. The client then sends a 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 Binding Request to this mapped address from a different port. If the
client receives its own request, the NAT hairpins connections. This client receives its own request, the NAT hairpins connections. This
skipping to change at page 12, line 19 skipping to change at page 11, line 30
Some NATs exhibit different behavior when forwarding fragments than Some NATs exhibit different behavior when forwarding fragments than
when forwarding a single-frame datagram. In particular, some NATs do when forwarding a single-frame datagram. In particular, some NATs do
not hairpin fragments at all and some platforms discard fragments not hairpin fragments at all and some platforms discard fragments
under load. To diagnose this behavior, STUN messages may be sent under load. To diagnose this behavior, STUN messages may be sent
with the PADDING attribute, which simply inserts additional space with the PADDING attribute, which simply inserts additional space
into the message. By forcing the STUN message to be divided into into the message. By forcing the STUN message to be divided into
multiple fragments, the NAT's behavior can be observed. multiple fragments, the NAT's behavior can be observed.
All of the previous tests can be performed with PADDING if a NAT's All of the previous tests can be performed with PADDING if a NAT's
fragment behavior is important for an application, or only those fragment behavior is important for an application, or only those
tests which are most interesting to the application can be retested. tests that are most interesting to the application can be retested.
PADDING only applies to UDP datagrams. PADDING can not be used with PADDING only applies to UDP datagrams. PADDING can not be used with
RESPONSE-PORT. RESPONSE-PORT.
3.6. Detecting a Generic Application Level Gateways (ALG) 3.6. Detecting a Generic Application Level Gateway (ALG)
A number of NAT boxes are now being deployed into the market which A number of NAT boxes are now being deployed into the market that try
try to provide "generic" ALG functionality. These generic ALGs hunt to provide "generic" ALG functionality. These generic ALGs hunt for
for IP addresses, either in text or binary form within a packet, and IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This behavior can be detected rewrite them if they match a binding. This behavior can be detected
because the STUN server returns both the MAPPED-ADDRESS and XOR- because the STUN server returns both the MAPPED-ADDRESS and XOR-
MAPPED-ADDRESS in the same response. If the result in the two does 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 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. apples to UDP and TCP, but not TLS over TCP connections.
4. Discovery Process 4. Discovery Process
This section provides a descriptive overview of how the NAT Behavior This section provides a descriptive overview of how the NAT Behavior
Discovery usage primitives allow checks to be made to discover the Discovery usage primitives allow checks to be made to discover the
current behaviour of the NAT or NATs an application is behind. These current behavior of the NAT or NATs an application is behind. These
tests can only give the instantaneous behaviour of a NAT; it has been tests can only give the instantaneous behavior of a NAT; it has been
found that NATs can change behaviour under load and over time. The found that NATs can change behavior under load and over time. The
results of these tests therefore can be regarded as upper bounds---an results of these tests therefore can be regarded as upper bounds --
application must assume that NAT behaviour can become more an application must assume that NAT behavior can become more
restrictive at any time. Results from tests performed using a restrictive at any time. Results from tests performed using a
particular port on the client may also not indicate the behavior particular port on the client may also not indicate the behavior
experienced by a different port, as described inSection 4.1. experienced by a different port, as described in Section 4.1.
Definitions for NAT filtering and mapping behaviour are from Definitions for NAT filtering and mapping behavior are from
[RFC4787]. The tests described here are for UDP connectivity, NAT [RFC4787]. The tests described here are for UDP connectivity, NAT
mapping behaviour, NAT filtering behaviour, and NAT binding lifetime mapping behavior, NAT filtering behavior, and NAT binding lifetime
discovery; additional tests could be designed using this usage's discovery; additional tests could be designed using this usage's
mechanisms. The tests described below include only tests that can be mechanisms. The tests described below include only tests that can be
performed using a client with a single IP address. A client with performed using a client with a single IP address. A client with
multiple IP addresses (or multiple clients collaborating) behind the multiple IP addresses (or multiple clients collaborating) behind the
same NAT can combine their probes to test additional aspects of NAT same NAT can combine their probes to test additional aspects of NAT
behavior, such as port overloading. This section provides a behavior, such as port overloading. This section provides a
descriptive overview of how the primitives provided by the STUN descriptive overview of how the primitives provided by the STUN
attributes in this specification may be used to perform behavior attributes in this specification may be used to perform behavior
tests. tests.
skipping to change at page 13, line 32 skipping to change at page 12, line 42
o Because mapping behavior can vary on a port-by-port basis, an o Because mapping behavior can vary on a port-by-port basis, an
application should perform its tests using the source port application should perform its tests using the source port
intended for use by the application whenever possible. If it intended for use by the application whenever possible. If it
intends to use multiple source ports, it should repeat these tests intends to use multiple source ports, it should repeat these tests
for each source port. Such tests should be performed sequentially for each source port. Such tests should be performed sequentially
to reduce load on the NAT. to reduce load on the NAT.
o Because the results of some diagnostic checks depend on previous o Because the results of some diagnostic checks depend on previous
state in the NAT created by prior traffic, the tests should be state in the NAT created by prior traffic, the tests should be
performed using a source port that has not generated recent performed using a source port that has not generated recent
traffic. Therefore the application should use a random source traffic. Therefore, the application should use a random source
port or ensure that no traffic has previously occurred on the port or ensure that no traffic has previously occurred on the
selected port prior to performing tests, generally by allocating a selected port prior to performing tests, generally by allocating a
port and holding it unused for at least 15 minutes prior to the port and holding it unused for at least 15 minutes prior to the
tests. tests.
Ensuring both of these preconditions can be challenging, particularly Ensuring both of these preconditions can be challenging, particularly
for a device or application wishing to perform Behavior Discovery for a device or application wishing to perform Behavior Discovery
tests at startup. The following guidelines are suggested for tests at startup. The following guidelines are suggested for
reducing the likelihood of problems: reducing the likelihood of problems:
o An application intended to operate behind a NAT should not attempt o An application intended to operate behind a NAT should not attempt
to allocate a specific or well-known port. Because such software to allocate a specific or well-known port. Because such software
must be designed to interoperate using whatever port is mapped to must be designed to interoperate using whatever port is mapped to
it by the NAT, the specific port is unnecessary. Instead, on it by the NAT, the specific port is unnecessary. Instead, on
startup a random port should be selected (see below for startup, a random port should be selected (see below for
recommended ranges). An application, particularly on an embedded recommended ranges). An application, particularly on an embedded
device, should not rely on the host operating system to select the device, should not rely on the host operating system to select the
next available port, because that might result in the application next available port because that might result in the application
receiving the same port on each restart. An application using the receiving the same port on each restart. An application using the
same port between restarts may not receive accurate results from same port between restarts may not receive accurate results from
Behavior Discovery tests that are intended to test state-related Behavior Discovery tests that are intended to test state-related
behavior of NATs, such as filtering and binding lifetime. behavior of NATs, such as filtering and binding lifetime.
o An application requiring multiple ports, such as separate ports o An application requiring multiple ports, such as separate ports
for control and media, should allocate those ports on startup when for control and media, should allocate those ports on startup when
possible. Even if there is no immediate need for media flow, if possible. Even if there is no immediate need for media flow, if
Behavior Discovery tests will be run on those ports, allocating Behavior Discovery tests will be run on those ports, allocating
them early will allow them to be left idle, increasing the chance them early will allow them to be left idle, increasing the chance
skipping to change at page 14, line 28 skipping to change at page 13, line 38
without being able to perform complete Behavior Discovery tests on without being able to perform complete Behavior Discovery tests on
those ports. In those cases, an application should randomly those ports. In those cases, an application should randomly
select its ports from a range likely to receive the same treatment select its ports from a range likely to receive the same treatment
by the NAT. This document recommends ranges of 32768-49151, which by the NAT. This document recommends ranges of 32768-49151, which
is the upper end of IANA's Registered Ports range, and 49152- is the upper end of IANA's Registered Ports range, and 49152-
65535, which is IANA's Dynamic and/or Private port range, for 65535, which is IANA's Dynamic and/or Private port range, for
random selection. To attempt to characterize a NAT's general random selection. To attempt to characterize a NAT's general
treatment of ports in these ranges, a small number of ports within treatment of ports in these ranges, a small number of ports within
a range can be randomly selected and characterized. a range can be randomly selected and characterized.
Those tests particularly sensistive to prior state on a NAT will be Those tests particularly sensitive to prior state on a NAT will be
indicated below. indicated below.
4.2. Checking for UDP Connectivity with the STUN Server 4.2. Checking for UDP Connectivity with the STUN Server
The client sends a STUN Binding Request to a server. This causes the 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 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 request came from. If this test yields no response, the client knows
right away that it does not have UDP connectivity with the STUN right away that it does not have UDP connectivity with the STUN
server. This test requires only STUN [RFC5389] functionality. server. This test requires only STUN [RFC5389] functionality.
skipping to change at page 15, line 26 skipping to change at page 14, line 40
In test I, the client performs the UDP connectivity test. The server In test I, the client performs the UDP connectivity test. The server
will return its alternate address and port in OTHER-ADDRESS in the will return its alternate address and port in OTHER-ADDRESS in the
binding response. If OTHER-ADDRESS is not returned, the server does binding response. If OTHER-ADDRESS is not returned, the server does
not support this usage and this test cannot be run. not support this usage and this test cannot be run.
In test II, the client sends a binding request to the primary address 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 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 and change-IP. This will cause the server to send its response from
its alternate IP address and alternate port. If the client receives its alternate IP address and alternate port. If the client receives
a response the current behaviour of the NAT is Endpoint-Independent a response, the current behavior of the NAT is Endpoint-Independent
Filtering. Filtering.
If no response is received, test III must be performed to distinguish If no response is received, test III must be performed to distinguish
between Address-Dependent Filtering and Address and Port-Dependent between Address-Dependent Filtering and Address and Port-Dependent
Filtering. In test III, the client sends a binding request to the Filtering. In test III, the client sends a binding request to the
original server address with CHANGE-REQUEST set to change-port. If original server address with CHANGE-REQUEST set to change-port. If
the client receives a response the current behaviour is Address- the client receives a response, the current behavior is Address-
Dependent Filtering; if no response is received the current behaviour Dependent Filtering; if no response is received, the current behavior
is Address and Port-Dependent Filtering. is Address and Port-Dependent Filtering.
4.5. Combining and Ordering Tests 4.5. Combining and Ordering Tests
Clients may wish to combine and parallelize these tests to reduce the Clients may wish to combine and parallelize these tests to reduce the
number of packets sent and speed the discovery process. For example, number of packets sent and speed the discovery process. For example,
test I of the filtering and mapping tests also checks if UDP is test I of the filtering and mapping tests also checks if UDP is
blocked. Furthermore, an application or user may not need as much blocked. Furthermore, an application or user may not need as much
detail as these sample tests provide. For example, establishing detail as these sample tests provide. For example, establishing
connectivity between nodes becomes significantly more difficult if a connectivity between nodes becomes significantly more difficult if a
NAT has any behavior other than endpoint-independent mapping, which NAT has any behavior other than Endpoint-Independent Mapping, which
requires only test I and II of Section 4.3. An application requires only test I and II of Section 4.3. An application that
determining its NAT does not always provide independent mapping might determines its NAT does not always provide Endpoint-Independent
notify the user if no relay is configured, whereas an application Mapping might notify the user if no relay is configured, whereas an
behind a NAT that provides endpoint-independent mapping might not application behind a NAT that provides Endpoint-Independent Mapping
notify the user until a subsequent connection actually fails or might might not notify the user until a subsequent connection actually
provide a less urgent notification that no relay is configured. Such fails or might provide a less urgent notification that no relay is
a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but configured. Such a test does not alleviate the need for [RFC5245],
it does provide some information regarding whether ICE is likely to but it does provide some information regarding whether ICE is likely
be successful establishing non-relayed connections. to be successful establishing non-relayed connections.
Care must be taken when combining and parallelizing tests, due to the Care must be taken when combining and parallelizing tests, due to the
sensitivity of certain tests to prior state on the NAT and because 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 some NAT devices have an upper limit on how quickly bindings will be
allocated. Section 5 restricts the rate at which clients may begin allocated. Section 5 restricts the rate at which clients may begin
new STUN transactions. new STUN transactions.
4.6. Binding Lifetime Discovery 4.6. Binding Lifetime Discovery
STUN can also be used to probe the lifetimes of the bindings created 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 by the NAT. Such tests are sensitive to prior state on the NAT. For
many NAT devices, an absolute refresh interval cannot be determined; many NAT devices, an absolute refresh interval cannot be determined;
bindings might be closed quicker under heavy load or might not behave bindings might be closed more quickly under heavy load or might not
as the tests suggest. For this reason applications that require behave as the tests suggest. For this reason, applications that
reliable bindings must send keep-alives as frequently as required by require reliable bindings must send keepalives as frequently as
all NAT devices that will be encountered. Suggested refresh required by all NAT devices that will be encountered. Suggested
intervals are outside the scope of this document. ICE refresh intervals are outside the scope of this document. [RFC5245]
[I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] have and OUTBOUND [RFC5626] have suggested refresh intervals.
suggested refresh intervals.
Determining the binding lifetime relies on two separate source ports Determining the binding lifetime relies on two separate source ports
being used to send STUN Binding Requests to the STUN server. The 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 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 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 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 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 be sent to the binding established to port X. If the binding for
X has timed out, that response will not be received. By varying the port X has timed out, that response will not be received. By varying
time between the original Binding Request sent from X and the the time between the original Binding Request sent from X and the
subsequent request sent from Y, the client can determine the binding subsequent request sent from Y, the client can determine the binding
lifetime. lifetime.
To determine the binding lifetime, the client first sends a Binding To determine the binding lifetime, the client first sends a Binding
Request to the server from a particular source port, X. This creates Request to the server from a particular source port, X. This creates
a binding in the NAT. The response from the server contains a a binding in the NAT. The response from the server contains a
MAPPED-ADDRESS attribute, providing the public address and port on MAPPED-ADDRESS attribute, providing the public address and port on
the NAT. Call this Pa and Pp, respectively. The client then starts 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 a timer with a value of T seconds. When this timer fires, the client
sends another Binding Request to the server, using the same sends another Binding Request to the server, using the same
destination address and port, but from a different source port, Y. destination address and port, but from a different source port, Y.
This request contains an RESPONSE-PORT attribute, set to Pp, to This request contains an RESPONSE-PORT attribute, set to Pp, to
request the response be delivered to (Pa,Pp). This will create a new request the response be delivered to (Pa, Pp). This will create a
binding on the NAT, and cause the STUN server to send a Binding 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 Response that would match the old binding, (Pa, Pp), if it still
exists. If the client receives the Binding Response on port X, it exists. If the client receives the Binding Response on port X, it
knows that the binding has not expired. If the client receives the knows that the binding has not expired. If the client receives the
Binding Response on port Y (which is possible if the old binding Binding Response on port Y (which is possible if the old binding
expired, and the NAT allocated the same public address and port to 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 the new binding), or receives no response at all, it knows that the
binding has expired. binding has expired.
Because some NATs only refresh bindings when outbound traffic is Because some NATs only refresh bindings when outbound traffic is
sent, the client must resend a binding request from the original sent, the client must resend a binding request from the original
source port before beginning a second test with a different value of 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 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 binary search through T, arriving eventually at the value where the
response is not received for any timer greater than T, but is response is not received for any timer greater than T, but is
received for any timer less than T. Note also that the binding received for any timer less than T. Note also that the binding
refresh behavior (outbound only or all traffic) can be determined by refresh behavior (outbound only or all traffic) can be determined by
sending multiple Binding Requests from port Y without refreshes from sending multiple Binding Requests from port Y without refreshes from
the original source port X. the original source port X.
This discovery process takes quite a bit of time and is something 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 that will typically be run in the background on a device once it
boots. boots.
It is possible that the client can get inconsistent results each time 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 this process is run. For example, if the NAT should reboot, or be
reset for some reason, the process may discover a lifetime than is reset for some reason, the process may discover a lifetime that is
shorter than the actual one. Binding lifetime may also be dependent shorter than the actual one. Binding lifetime may also be dependent
on the traffic load on the NAT. For this reason, implementations are on the traffic load on the NAT. For this reason, implementations are
encouraged to run the test numerous times and be prepared to get encouraged to run the test numerous times and be prepared to get
inconsistent results. inconsistent results.
Like the other diagnostics, this test is inherently unstable. In Like the other diagnostics, this test is inherently unstable. In
particular, an overloaded NAT might reduce binding lifetime to shed particular, an overloaded NAT might reduce binding lifetime to shed
load. A client might find this diagnostic useful at startup, for load. A client might find this diagnostic useful at startup, for
example setting the initial keepalive interval on its connection to example, setting the initial keepalive interval on its connection to
the server to 10 seconds while beginning this check. After the server to 10 seconds while beginning this check. After
determining the current lifetime, the keepalive interval used by the determining the current lifetime, the keepalive interval used by the
connection to the server can be set to this appropriate value. connection to the server can be set to this appropriate value.
Subsequent checks of the binding lifetime can then be performed using Subsequent checks of the binding lifetime can then be performed using
the keepalives in the server connection. The STUN Keepalive Usage the keepalives in the server connection. The STUN Keepalive Usage
[I-D.ietf-sip-outbound] provides a response that confirms the [RFC5626] provides a response that confirms the connection is open
connection is open and allows the client to check that its mapped and allows the client to check that its mapped address has not
address has not changed. As that provides both the keepalive action changed. As that provides both the keepalive action and diagnostic
and diagnostic that it is working, it should be preferred over any that it is working, it should be preferred over any attempt to
attempt to characterize the connection by a secondary technique. characterize the connection by a secondary technique.
5. Client Behavior 5. Client Behavior
Unless otherwise specified here, all procedures for preparing, Unless otherwise specified here, all procedures for preparing,
sending, and processing messages as described in the STUN Binding sending, and processing messages as described in the STUN Binding
Usage [RFC5389] are followed. Usage [RFC5389] are followed.
As support for RESPONSE-PORT is optional a client MUST be prepared to As support for RESPONSE-PORT is optional, a client MUST be prepared
receive a 420 (Unknown Attribute) error to requests that include to receive a 420 (Unknown Attribute) error to requests that include
RESPONSE-PORT. Support for OTHER-ADDRESS and CHANGE-REQUEST is RESPONSE-PORT. Support for OTHER-ADDRESS and CHANGE-REQUEST is
optional, but MUST be supported by servers advertised via SRV, as optional, but MUST be supported by servers advertised via SRV, as
described below. This is to allow the use of PADDING and RESPONSE- described below. This is to allow the use of PADDING and RESPONSE-
PORT in applications where servers do not have multiple IP addresses. PORT in applications where servers do not have multiple IP addresses.
Clients MUST be prepared to receive a 420 for requests that include Clients MUST be prepared to receive a 420 for requests that include
CHANGE-REQUEST when OTHER-ADDRESS was not received in Binding CHANGE-REQUEST when OTHER-ADDRESS was not received in Binding
Response messages from the server. Response messages from the server.
If an application makes use of the NAT Behavior Discovery STUN usage If an application makes use of the NAT Behavior Discovery STUN usage
by multiplexing it in a flow with application traffic, a FINGERPRINT by multiplexing it in a flow with application traffic, a FINGERPRINT
skipping to change at page 18, line 32 skipping to change at page 17, line 44
When PADDING is used, it SHOULD be equal to the MTU of the outgoing When PADDING is used, it SHOULD be equal to the MTU of the outgoing
interface. interface.
Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response
unless they are using authentication with a provider of STUN servers unless they are using authentication with a provider of STUN servers
that is aware of the topology requirements of the tests being that is aware of the topology requirements of the tests being
performed. performed.
A client SHOULD NOT generate more than ten new STUN transactions per A client SHOULD NOT generate more than ten new STUN transactions per
second and SHOULD pace them such that the RTOs do not synchronize the second and SHOULD pace them such that the retransmission timeouts
retransmissions of each transaction. (RTOs) do not synchronize the retransmissions of each transaction.
5.1. Discovery 5.1. Discovery
Unless the user or application is aware of the transport address of a Unless the user or application is aware of the transport address of a
STUN server supporting the NAT Behavior Discovery usage through other STUN server supporting the NAT Behavior Discovery usage through other
means, a client is configured with the domain name of the provider of means, a client is configured with the domain name of the provider of
the STUN servers. The domain is resolved to a transport address the STUN servers. The domain is resolved to a transport address
using SRV procedures [RFC2782]. The mechanism for configuring the using SRV procedures [RFC2782]. The mechanism for configuring the
client with the domain name of the STUN servers or of acquiring a client with the domain name of the STUN servers or of acquiring a
specific transport address is out of scope for this document. specific transport address is out of scope for this document.
For the Behavior Discovery Usage the service name is "stun-behavior" For the Behavior Discovery usage, the service name is "stun-behavior"
for UDP and TCP. The service name is "stun-behaviors" for TLS over for UDP and TCP. The service name is "stun-behaviors" for TLS over
TCP. Only "tcp" is defined as a protocol for "stun-behaviors". TCP. Only "tcp" is defined as a protocol for "stun-behaviors".
Other aspects of handling failures and default ports are followed as Other aspects of handling failures and default ports are followed as
described in STUN [RFC5389]. described in STUN [RFC5389].
5.2. Security 5.2. Security
Servers MAY require authentication before allowing a client to make Servers MAY require authentication before allowing a client to make
use of its services. The method for obtaining these credentials, use of its services. The method for obtaining these credentials,
should the server require them, is outside the scope of this usage. should the server require them, is outside the scope of this usage.
skipping to change at page 19, line 39 skipping to change at page 18, line 49
wildcard binding accomplishes this). TCP and TCP/TLS MUST use wildcard binding accomplishes this). TCP and TCP/TLS MUST use
different ports. If a server cannot allocate the same ports on two different ports. If a server cannot allocate the same ports on two
different IP address, then it MUST NOT include an OTHER-ADDRESS different IP address, then it MUST NOT include an OTHER-ADDRESS
attribute in any Response and MUST respond with a 420 (Unknown attribute in any Response and MUST respond with a 420 (Unknown
Attribute) to any Request with a CHANGE-REQUEST attribute. A server Attribute) to any Request with a CHANGE-REQUEST attribute. A server
with only one IP address MUST NOT be advertised using the SRV service with only one IP address MUST NOT be advertised using the SRV service
name "stun-behavior" or "stun-behaviors". name "stun-behavior" or "stun-behaviors".
6.1. Preparing the Response 6.1. Preparing the Response
After performing all authentication and verification steps the server After performing all authentication and verification steps, the
begins processing specific to this Usage if the Request contains any server begins processing specific to this Usage if the Binding
request attributes defined in this document: RESPONSE-PORT, CHANGE- Request contains any request attributes defined in this document:
REQUEST, or PADDING. If the Request does not contain any attributes
from this document, OTHER-ADDRESS and RESPONSE-ORIGIN are still RESPONSE-PORT, CHANGE-REQUEST, or PADDING. If the Binding Request
included in the response. 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 The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in
its Response. its Response.
If the Request contains CHANGE-REQUEST attribute and the server does If the Request contains the CHANGE-REQUEST attribute and the server
not have an alternate address and port as described above, the server does not have an alternate address and port as described above, the
MUST generate an error response of type 420. server MUST generate an error response of type 420.
The source address and port of the Binding Response depend on the The source address and port of the Binding Response depend on the
value of the CHANGE-REQUEST attribute and on the address and port the value of the CHANGE-REQUEST attribute and on the address and port on
Binding Request was received on, and are summarized in Table 1. 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 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 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), IP address of the Binding Request (which will be either A1 or A2),
and Dp represent the destination port of the Binding Request (which and Dp represent the destination port of the Binding Request (which
will be either P1 or P2). Let Ca represent the other address, so 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 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 Cp represent the other port, so that if Dp is P1, Cp is P2. If Dp is
P2, Cp is P1. If the "change port" flag was set in CHANGE-REQUEST P2, Cp is P1. If the "change port" flag was set in the CHANGE-
attribute of the Binding Request, and the "change IP" flag was not REQUEST attribute of the Binding Request, and the "change IP" flag
set, the source IP address of the Binding Response MUST be Da and the was not set, the source IP address of the Binding Response MUST be Da
source port of the Binding Response MUST be Cp. If the "change IP" and the source port of the Binding Response MUST be Cp. If the
flag was set in the Binding Request, and the "change port" flag was "change IP" flag was set in the Binding Request, and the "change
not set, the source IP address of the Binding Response MUST be Ca and port" flag was not set, the source IP address of the Binding Response
the source port of the Binding Response MUST be Dp. When both flags MUST be Ca and the source port of the Binding Response MUST be Dp.
are set, the source IP address of the Binding Response MUST be Ca and When both flags are set, the source IP address of the Binding
the source port of the Binding Response MUST be Cp. If neither flag Response MUST be Ca and the source port of the Binding Response MUST
is set, or if the CHANGE-REQUEST attribute is absent entirely, the be Cp. If neither flag is set, or if the CHANGE-REQUEST attribute is
source IP address of the Binding Response MUST be Da and the source absent entirely, the source IP address of the Binding Response MUST
port of the Binding Response MUST be Dp. be Da and the source port of the Binding Response MUST be Dp.
+--------------------+----------------+-------------+---------------+ +--------------------+----------------+-------------+---------------+
| Flags | Source Address | Source Port | OTHER-ADDRESS | | Flags | Source Address | Source Port | OTHER-ADDRESS |
+--------------------+----------------+-------------+---------------+ +--------------------+----------------+-------------+---------------+
| none | Da | Dp | Ca:Cp | | none | Da | Dp | Ca:Cp |
| Change IP | Ca | Dp | Ca:Cp | | Change IP | Ca | Dp | Ca:Cp |
| Change port | Da | Cp | Ca:Cp | | Change port | Da | Cp | Ca:Cp |
| Change IP and | Ca | Cp | Ca:Cp | | Change IP and | Ca | Cp | Ca:Cp |
| Change port | | | | | Change port | | | |
+--------------------+----------------+-------------+---------------+ +--------------------+----------------+-------------+---------------+
Table 1: Impact of Flags on Packet Source and OTHER-ADDRESS Table 1: Impact of Flags on Packet Source and OTHER-ADDRESS
The server MUST add a RESPONSE-ORIGIN attribute to the Binding The server MUST add a RESPONSE-ORIGIN attribute to the Binding
Response, containing the source address and port used to send the Response, containing the source address and port used to send the
Binding Response. Binding Response.
If the server supports an alternate address and port the server MUST If the server supports an alternate address and port, the server MUST
add an OTHER-ADDRESS attribute to the Binding Response. This add an OTHER-ADDRESS attribute to the Binding Response. This
contains the source IP address and port that would be used if the 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 client had set the "change IP" and "change port" flags in the Binding
Request. As summarized in Table 1, these are Ca and Cp, Request. As summarized in Table 1, these are Ca and Cp,
respectively, regardless of the value of the CHANGE-REQUEST flags. respectively, regardless of the value of the CHANGE-REQUEST flags.
If the Request contained a PADDING attribute, PADDING MUST be If the Request contained a PADDING attribute, PADDING MUST be
included in the Binding Response. The server SHOULD use a length of 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 PADDING equal to the MTU on the outgoing interface, rounded up to an
even multiple of four bytes. If the Request also contains the even multiple of four bytes. If the Request also contains the
skipping to change at page 21, line 21 skipping to change at page 20, line 34
from STUN [RFC5389]. If authentication is being required, the server from STUN [RFC5389]. If authentication is being required, the server
MUST include a MESSAGE-INTEGRITY and associated attributes as MUST include a MESSAGE-INTEGRITY and associated attributes as
appropriate. A FINGERPRINT attribute is only required if the STUN appropriate. A FINGERPRINT attribute is only required if the STUN
messages are being multiplexed with application traffic that requires messages are being multiplexed with application traffic that requires
use of a FINGERPRINT to distinguish STUN messages. use of a FINGERPRINT to distinguish STUN messages.
An ALTERNATE-SERVER attribute MUST NOT be included with any other An ALTERNATE-SERVER attribute MUST NOT be included with any other
attribute defined in this specification. attribute defined in this specification.
When the server sends the Response, it is sent from the source When the server sends the Response, it is sent from the source
address as determined above and to the to the source address of the address as determined above and to the source address of the Request.
Request. If RESPONSE-PORT is present the server sends the reponse to If RESPONSE-PORT is present, the server sends the response to that
that port instead of the originating port. port instead of the originating port.
7. New Attributes 7. New Attributes
This document defines several STUN attributes that are required for This document defines several STUN attributes that are required for
NAT Behavior Discovery. These attributes are all used only with NAT Behavior Discovery. These attributes are all used only with
Binding Requests and Binding Responses. CHANGE-REQUEST was Binding Requests and Binding Responses. CHANGE-REQUEST was
originally defined in RFC3489 [RFC3489] but is redefined here as that originally defined in RFC 3489 [RFC3489] but is redefined here as
document is obsoleted by [RFC5389]. that document is obsoleted by [RFC5389].
Comprehension-required range (0x0000-0x7FFF): Comprehension-required range (0x0000-0x7FFF):
0x0003: CHANGE-REQUEST 0x0003: CHANGE-REQUEST
0x0026: PADDING 0x0026: PADDING
0x0027: RESPONSE-PORT 0x0027: RESPONSE-PORT
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF):
0x802b: RESPONSE-ORIGIN 0x802b: RESPONSE-ORIGIN
0x802c: OTHER-ADDRESS 0x802c: OTHER-ADDRESS
7.1. Representing Transport Addresses 7.1. Representing Transport Addresses
Whenever an attribute contains a transport IP address and port, it Whenever an attribute contains a transport IP address and port, it
has the same format as MAPPED-ADDRESS. Similarly, the XOR- has the same format as MAPPED-ADDRESS. Similarly, the XOR-
attributes have the same format as XOR-MAPPED-ADDRESS[RFC5389]. attributes have the same format as XOR-MAPPED-ADDRESS [RFC5389].
7.2. CHANGE-REQUEST 7.2. CHANGE-REQUEST
The CHANGE-REQUEST attribute contains two flags to control the IP The CHANGE-REQUEST attribute contains two flags to control the IP
address and port the server uses to send the response. These flags address and port that the server uses to send the response. These
are called the "change IP" and "change port" flags. The CHANGE- flags are called the "change IP" and "change port" flags. The
REQUEST attribute is allowed only in the Binding Request. The CHANGE-REQUEST attribute is allowed only in the Binding Request. The
"change IP" and "change port" flags are useful for determining the "change IP" and "change port" flags are useful for determining the
current filtering behavior of a NAT. They instruct the server to current filtering behavior of a NAT. They instruct the server to
send the Binding Responses from the alternate source IP address send the Binding Responses from the alternate source IP address
and/or alternate port. The CHANGE-REQUEST attribute is optional in and/or alternate port. The CHANGE-REQUEST attribute is optional in
the Binding Request. the Binding Request.
The attribute is 32 bits long, although only two bits (A and B) are The attribute is 32 bits long, although only two bits (A and B) are
used: used:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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| |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: The meanings of the flags are:
A: This is the "change IP" flag. If true, it requests the server to 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 send the Binding Response with a different IP address than the one
skipping to change at page 22, line 51 skipping to change at page 22, line 14
7.4. OTHER-ADDRESS 7.4. OTHER-ADDRESS
The OTHER-ADDRESS attribute is used in Binding Responses. It informs 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 of the source IP address and port that would be used if
the client requested the "change IP" and "change port" behavior. the client requested the "change IP" and "change port" behavior.
OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the
server has a second IP address. server has a second IP address.
OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from
RFC3489 [RFC3489]because it is simply a new name with the same RFC 3489 [RFC3489] because it is simply a new name with the same
semantics as CHANGED-ADDRESS. It has been renamed to more clearly semantics as CHANGED-ADDRESS. It has been renamed to more clearly
indicate its function. indicate its function.
7.5. RESPONSE-PORT 7.5. RESPONSE-PORT
The REPONSE-PORT attribute contains a port. The RESPONSE-PORT The RESPONSE-PORT attribute contains a port. The RESPONSE-PORT
attribute can be present in the Binding Request and indicates which attribute can be present in the Binding Request and indicates which
port the Binding Response will be sent to. For servers which support port the Binding Response will be sent to. For servers which support
the RESPONSE-PORT attribute, the Binding Response MUST be transmited the RESPONSE-PORT attribute, the Binding Response MUST be transmitted
to the source IP address of the Binding Request and the port 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. 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 When not present, the server sends the Binding Response to the source
IP address and port of the Binding Request. The server MUST NOT IP address and port of the Binding Request. The server MUST NOT
process a request containing a RESPONSE-PORT and a PADDING attribute. process a request containing a RESPONSE-PORT and a PADDING attribute.
The RESPONSE-PORT attribute is optional in the Binding Request. The RESPONSE-PORT attribute is optional in the Binding Request.
Server support for RESPONSE-PORT is optional. Server support for RESPONSE-PORT is optional.
RESPONSE-PORT is a 16 bit unsigned integer in network byte order RESPONSE-PORT is a 16-bit unsigned integer in network byte order
followed by 2 bytes of padding. Allowable values of RESPONSE-PORT followed by 2 bytes of padding. Allowable values of RESPONSE-PORT
are 0-65536. are 0-65536.
7.6. PADDING 7.6. PADDING
The PADDING attribute allows for the entire message to be padded to The PADDING attribute allows for the entire message to be padded to
force the STUN message to be divided into IP fragments. PADDING force the STUN message to be divided into IP fragments. PADDING
consists entirely of a freeform string, the value of which does not consists entirely of a free-form string, the value of which does not
matter. PADDING can be used in either Binding Requests or Binding matter. PADDING can be used in either Binding Requests or Binding
Responses. Responses.
PADDING MUST NOT be longer than the length that brings the total IP 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 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. outgoing interface, rounded up to an even multiple of four bytes.
Because STUN messages with PADDING are intended to test the behavior Because STUN messages with PADDING are intended to test the behavior
of UDP fragments, they are an exception to the usual rule that STUN of UDP fragments, they are an exception to the usual rule that STUN
messages be less than the MTU of the path. messages be less than the MTU of the path.
8. IAB Considerations 8. IAB Considerations
The IAB has studied the problem of ``Unilateral Self Address The IAB has studied the problem of "Unilateral Self-Address Fixing"
Fixing'', which is the general process by which a client attempts to (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 determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism RFC 3424 through a collaborative protocol reflection mechanism [RFC3424]. The
[RFC3424]. The STUN NAT Behavior Discovery usage is an example of a STUN NAT Behavior Discovery usage is an example of a protocol that
protocol that performs this type of function. The IAB has mandated performs this type of function. The IAB has mandated that any
that any protocols developed for this purpose document a specific set protocols developed for this purpose document a specific set of
of considerations. This section meets those requirements. considerations. This section meets those requirements.
8.1. Problem Definition 8.1. Problem Definition
From RFC 3424 [RFC3424], any UNSAF proposal must provide: From RFC 3424 [RFC3424], any UNSAF proposal must provide:
Precise definition of a specific, limited-scope problem that is to Precise definition of a specific, limited-scope problem that is to
be solved with the UNSAF proposal. A short term fix should not be be solved with the UNSAF proposal. A short term fix should not be
generalized to solve other problems; this is why "short term fixes generalized to solve other problems. Such generalizations lead to
usually aren't". 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 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, usage is for a client, which may be located behind a NAT of any type,
to determine the instantaneous characteristics of that NAT in order to determine the instantaneous characteristics of that NAT. This
to either diagnose the cause of problems experienced by that or other determination allows either the diagnosis of the cause of problems
applications or for an application to modify its behavior based on experienced by that or other applications or the modification of an
the current behavior of the NAT and an appropriate statistical model application's behavior based on the current behavior of the NAT and
of the behavior required for the application to succeed. an appropriate statistical model of the behavior required for the
application to succeed.
8.2. Exit Strategy 8.2. Exit Strategy
From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Description of an exit strategy/transition plan. The better short Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed. as the appropriate technology is deployed.
The STUN NAT Behavior Discovery usage does not itself provide an exit 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 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 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, this specification will not be necessary with those v6-to-v4 NATs
because the IETF is planning to adequately describe their operation. because the IETF is planning to adequately describe their operation.
This specification will be of no interest for v6 to v6 connectivity. This specification will be of no interest for v6-to-v6 connectivity.
8.3. Brittleness Introduced by STUN NAT Behavior Discovery 8.3. Brittleness Introduced by STUN NAT Behavior Discovery
From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Discussion of specific issues that may render systems more Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at "brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition. debugging challenges, and make it harder to transition.
The STUN NAT Behavior Discovery usage allows a client to determine The STUN NAT Behavior Discovery usage allows a client to determine
the current behavior of a NAT. This information can be quite useful the current behavior of a NAT. This information can be quite useful
to a developer or network administrator outside of an application, to a developer or network administrator outside of an application,
and as such can be used to diagnose the brittleness induced in and as such can be used to diagnose the brittleness induced in
another application. When used within an application itself, STUN another application. When used within an application itself, STUN
NAT Behavior Discovery allows the application to adjust its behavior NAT Behavior Discovery allows the application to adjust its behavior
according to the current behavior of the NAT. This draft is according to the current behavior of the NAT. This document is
experimental because the extent to which brittleness is introduced to experimental because the extent to which brittleness is introduced to
an application relying on the Behavior Discovery usage is unclear and an application relying on the Behavior Discovery usage is unclear and
must be carefully evaluated by the designers of the protocol making must be carefully evaluated by the designers of the protocol making
use of it. The experimental test for this protocol is essentially use of it. The experimental test for this protocol is essentially
determining whether an application can be made less brittle through determining whether an application can be made less brittle through
the use of behavior-discovery information than it would be if the use of behavior-discovery information than it would be if
attempted to make use of the network without any awareness of the attempted to make use of the network without any awareness of the
NATs its traffic must pass through. NATs its traffic must pass through.
8.4. Requirements for a Long Term Solution 8.4. Requirements for a Long-Term Solution
From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Identify requirements for longer term, sound technical solutions Identify requirements for longer-term, sound technical solutions
-- contribute to the process of finding the right longer term -- contribute to the process of finding the right longer-term
solution. solution.
As long as v4 NATs are present, means of adapting to their presence 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 will be required. As described above, well-behaved v6 to v4 NATs and
direct v6 to v6 connections will not require behavior direct v6 to v6 connections will not require behavior
characterization. characterization.
8.5. Issues with Existing NAPT Boxes 8.5. Issues with Existing NAPT Boxes
From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports. existing deployed NATs and experience reports.
This usage provides a set of generic attributes that can be assembled This usage provides a set of generic attributes that can be assembled
to test many types of NAT behavior. While tests for the most to test many types of NAT behavior. While tests for the most
commonly known NAT box behaviors are described, the BEHAVE mailing commonly known NAT box behaviors are described, the BEHAVE mailing
list regularly has descriptions of new behaviors, some of which may list regularly has descriptions of new behaviors, some of which may
not be readily detected using the tests described herein. However, not be readily detected using the tests described herein. However,
the techniques described in this usage can be assembled in different the techniques described in this usage can be assembled in different
combinations to test NAT behaviors not now known or envisioned. combinations to test NAT behaviors not now known or envisioned.
9. IANA Considerations 9. IANA Considerations
This specification requests that IANA make additions to the "STUN
Attributes Registry" and "STUN Error Code Registry".
9.1. STUN Attribute Registry 9.1. STUN Attribute Registry
This specification defines several new STUN attributes. This section This specification defines several new STUN attributes. IANA has
directs IANA to add these new protocol elements to the IANA registry added these new protocol elements to the "STUN Attributes" registry.
of STUN protocol elements.
0x0003: CHANGE-REQUEST 0x0003: CHANGE-REQUEST
0x0027: RESPONSE-PORT 0x0027: RESPONSE-PORT
0x0026: PADDING 0x0026: PADDING
0x8027: CACHE-TIMEOUT 0x8027: CACHE-TIMEOUT
0x802b: RESPONSE-ORIGIN 0x802b: RESPONSE-ORIGIN
0x802c: OTHER-ADDRESS 0x802c: OTHER-ADDRESS
9.2. SRV Registry 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" This specification defines the "stun-behavior" and "stun-behaviors"
SRV service names. "stun-behavior" may be used with SRV protocol SRV service names. "stun-behavior" may be used with SRV protocol
specifiers "udp" and "tcp". "stun-behaviors" may only be specified specifiers "udp" and "tcp". "stun-behaviors" may only be specified
with "tcp". Thus, the allowable SRV queries are: with "tcp". Thus, the allowable SRV queries are:
_stun-behavior._udp UDP _stun-behavior._udp UDP
_stun-behavior._tcp TCP _stun-behavior._tcp TCP
_stun-behaviors._tcp TLS over TCP _stun-behaviors._tcp TLS over TCP
10. Security Considerations 10. Security Considerations
This usage inherits the security considerations of STUN [RFC5389]. This usage inherits the security considerations of STUN [RFC5389].
This usage adds several new attributes; security considerations for This usage adds several new attributes; security considerations for
those are detailed here. those are detailed here.
skipping to change at page 26, line 35 skipping to change at page 26, line 12
This usage adds several new attributes; security considerations for This usage adds several new attributes; security considerations for
those are detailed here. those are detailed here.
OTHER-ADDRESS does not permit any new attacks; it provides another OTHER-ADDRESS does not permit any new attacks; it provides another
place where an attacker can impersonate a STUN server but it is not place where an attacker can impersonate a STUN server but it is not
an interesting attack. An attacker positioned where it can an interesting attack. An attacker positioned where it can
compromise the Binding Response can completely hide the STUN server compromise the Binding Response can completely hide the STUN server
from the client. from the client.
o Requests containing both RESPONSE-PORT and PADDING are rejected by o Requests containing both RESPONSE-PORT and PADDING are rejected by
the server. This prevents an amplification attack which is the server. This prevents an amplification attack that is
targeted at the originating address. targeted at the originating address.
The only attack possible with the PADDING attribute is to have a The only attack possible with the PADDING attribute is to have a
large padding length which could cause a server to allocate a large large padding length that could cause a server to allocate a large
amount of memory. As servers will ignore any padding length greater amount of memory. As servers will ignore any padding length greater
than 64k so the scope of this attack is limited. In general, servers than 64K so the scope of this attack is limited. In general, servers
should not allocate more memory than the size of the received should not allocate more memory than the size of the received
datagram. This attack would only affect non-compliant datagram. This attack would only affect non-compliant
implementations. implementations.
RESPONSE-ORIGIN and RESPONSE-PORT do not provide any additional RESPONSE-ORIGIN and RESPONSE-PORT do not provide any additional
attacks. attacks.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank the authors of the original STUN The authors would like to thank the authors of the original STUN
skipping to change at page 27, line 33 skipping to change at page 27, line 7
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-outbound]
Jennings, C., "Managing Client Initiated Connections in
the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-20 (work in progress), June 2009.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
Appendix A. Change Log [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
RFC-EDITOR: Please remove this entire Change Log section while Traversal for Offer/Answer Protocols", RFC 5245,
formatting this document for publication. April 2010.
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00
o Only OTHER-ADDRESS, CHANGE-ADDRESS, and XOR-RESPONSE-TARGET
support is optional; support for PADDING and SOURCE-ADDRESS is now
mandatory
o PADDING is now a mandatory attribute
o OTHER-ADDRESS is returned in all binding responses if the server
has a second IP address
A.2. from draft-ietf-behave-nat-behavior-discovery-00
o Clarified that only servers with two IP addresses should have an
SRV entry
o Removed support for backward compatibility with 3489 clients by
removing non-XOR forms of attributes. Language states that
backward compatibility with 3489 clients is SHOULD NOT.
Compatibility with 3489 servers is left unspecified.
o PADDING is mandatory and language has been changed to indicate
that if a server supports PADDING it must either actually provide
the padding or return an error (can't support it but refuse to do
it)
o Require both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS to be returned
to support detection of generic ALGs
A.3. from draft-ietf-behave-nat-behavior-discovery-01
o Changed proposed status to experimental
o Made significant changes to the introduction and applicability
statements to reflect the experimental status
o Fixed the New Attributes and IANA considerations not listing the
same attribute numbers.
o Removed mandatory shared secret credentials in favor of the option
of rate limiting or credentials. Specified that credentials must
be obtained from the user or parent application.
o Made OTHER-ADDRESS and SOURCE-ADDRESS optional to address
compatibility with 3489bis clients. Renamed SOURCE-ADDRESS as
RESPONSE-ORIGIN to avoid conflicts with 3489.
o Renamed XOR-RESPONSE-ADDRESS to XOR-RESPONSE-TARGET
o Added discussion of FINGERPRINT and ALTERNATE-SERVER for
compliance with 3489bis stun usage definition requirements.
A.4. from draft-ietf-behave-nat-behavior-discovery-02
o fix terminology for endpoint-independent, address-dependent, and
address and port-dependent from rfc4787
o define the ALG detection to apply to UDP and TCP
o fix >From typo in 9.5
o added exception to single MTU size restriction for PADDING
o removed OPEN ISSUE about CHANGE-REQUEST IANA registry based on the
belief that we need to list that definition here now that 3489bis
is dropping it.
A.5. from draft-ietf-behave-nat-behavior-discovery-03
o moved semantics of PADDING usage into behavior sections rather
than attributes section
o removed reference to SERVER attribute
o removed Open Issues section
o Updated IAB considerations
A.6. from draft-ietf-behave-nat-behavior-discovery-04
o Clarified that behavior may vary by port used as well as by
destination IP/particular STUN server, and therefore specified
that all tests should be performed using the port the application
will use
o Added additional text on selecting random port/ensuring port has
been unused prior to starting filtering tests
o specified limit to start rate of tests and that tests
retransmissions should not synchronize
o additional explanatory text for XOR-RESPONSE-TARGET
o added SRV entry to IANA section and subdivided to match STUN
registries from 5389
o clarified that test combinations are non-normative
o Numerous clarifications
o Changed PADDING to default to interface MTU, and changed maximum
length to not make IP datagram exceed 64K
o Added text that server should allocate TCP and TCP/TLS
A.7. from draft-ietf-behave-nat-behavior-discovery-05
o In applicability section, add explicit requirement that citing
drafts must specify how they handle failure
o Add new subsection on selecting the source port used for tests,
covering both requirements that the same port be used for tests as
for the application and dependencies on previous bindings.
Reference that section explicitly for tests that are sensitive to
previous binding state.
o Change SRV discovery to stun-behavior for UDP and TCP and stun-
behaviors for TLS/TCP.
o Add SRV registry subsection to IANA section.
A.8. from draft-ietf-behave-nat-behavior-discovery-06
o Reworked the applicability section and provided more detail in the
P2P application example
o Additional clarification on the limits of the tests, and that the
described tests include only those utilizing a single source IP,
so can't test overloading.
o Several changes to clarify and make consistent security
requirements for XOR-RESPONSE-TARGET
o Numerous other clarifications in response to comments.
A.9. from draft-ietf-behave-nat-behavior-discovery-07
o Changed XOR-RESPONSE-ADDRESS to RESPONSE-PORT which resulted in
CACHE-TIMEOUT and XOR-REFLECTED-FROM. This resulted in a
simplification of the Security Considerations
o Fixed erroneous STUN expansions
o Clarification of when a fallback mechanism will be used.
o Numerous other clarifications in response to comments. [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
Authors' Addresses Authors' Addresses
Derek C. MacDonald Derek C. MacDonald
CounterPath Solutions, Inc. Skype
Suite 300, One Bentall Centre, 505 Burrard St Palo Alto, CA
Vancouver, BC V7X1M3 USA
Canada
Phone: +1-604-320-3344 EMail: derek.macdonald@gmail.com
Email: derek.macdonald@gmail.com
Bruce B. Lowekamp Bruce B. Lowekamp
MYMIC LLC Skype
1040 University Blvd., Suite 100 Palo Alto, CA
Portsmouth, VA 23703
USA USA
Email: bbl@lowekamp.net EMail: bbl@lowekamp.net
 End of changes. 125 change blocks. 
515 lines changed or deleted 361 lines changed or added

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