draft-ietf-behave-nat-behavior-discovery-01.txt   draft-ietf-behave-nat-behavior-discovery-02.txt 
BEHAVE D. MacDonald BEHAVE D. MacDonald
Internet-Draft CounterPath Solutions, Inc. Internet-Draft CounterPath Solutions, Inc.
Intended status: Standards Track B. Lowekamp Intended status: Experimental B. Lowekamp
Expires: December 29, 2007 SIPeerior Technologies and William Expires: May 20, 2008 SIPeerior Technologies and William
& Mary & Mary
June 27, 2007 November 17, 2007
NAT Behavior Discovery Using STUN NAT Behavior Discovery Using STUN
draft-ietf-behave-nat-behavior-discovery-01 draft-ietf-behave-nat-behavior-discovery-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2007. This Internet-Draft will expire on May 20, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This specification defines a usage of the Simple Traversal Underneath This specification defines an experimental usage of the Simple
Network Address Translators (NAT) (STUN) Protocol that discovers the Traversal Underneath Network Address Translators (NAT) (STUN)
presence and current behaviour of NATs and firewalls between the STUN Protocol that discovers the presence and current behaviour of NATs
client and the STUN server. and firewalls between the STUN client and the STUN server.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 5 2.1. Diagnostic Use . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 5 2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 6
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 6 2.3. Experimental Success . . . . . . . . . . . . . . . . . . . 6
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 6 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 7
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 6 3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 8
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 7 3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 8
3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 7 3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 8
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 9
4.1. Checking if UDP is Blocked . . . . . . . . . . . . . . . . 7 3.5. Determining Fragment Handling . . . . . . . . . . . . . . 9
4.2. Determining NAT Mapping Behavior . . . . . . . . . . . . . 8 3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 9
4.3. Determining NAT Filtering Behavior . . . . . . . . . . . . 8 4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Combining and Ordering Tests . . . . . . . . . . . . . . . 9 4.1. Checking if UDP is Blocked . . . . . . . . . . . . . . . . 10
4.5. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 9 4.2. Determining NAT Mapping Behavior . . . . . . . . . . . . . 10
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Determining NAT Filtering Behavior . . . . . . . . . . . . 10
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Combining and Ordering Tests . . . . . . . . . . . . . . . 11
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 12 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 12 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Representing Transport Addresses . . . . . . . . . . . . . 15 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 14
7.3. SOURCE-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 16 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 17
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Representing Transport Addresses . . . . . . . . . . . . . 17
7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 16 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 17
7.6. XOR-RESPONSE-ADDRESS . . . . . . . . . . . . . . . . . . . 16 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 18
7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 18
7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 17 7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 18
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 17 7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 19
8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 18 7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 18 7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 20
8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 18 8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 20
8.4. Requirements for a Long Term Solution . . . . . . . . . . 19 8.1. 481 Connection does not exist . . . . . . . . . . . . . . 20
8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 19 8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 21
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4. Requirements for a Long Term Solution . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 22 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 23 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 26
A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 26
A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Applicability 1. Applicability
This STUN usage does not allow an application behind a NAT to make an This experimental STUN usage does not allow an application behind a
absolute determination of the NAT's characteristics. NAT devices do NAT to make an absolute determination of the NAT's characteristics.
not behave consistently enough to predict future behaviour with any NAT devices do not behave consistently enough to predict future
guarantee. This STUN usage provides information about observable behaviour with any guarantee. This STUN usage provides information
transient behavior; it only truly determines a NAT's behavior with about observable transient behavior; it only truly determines a NAT's
regard to the STUN server used at the instant the test is run. behavior with regard to the STUN server used at the instant the test
Applications requiring reliable reach must establish a communication is run. Applications requiring reliable reach between two particular
channel through a NAT using another technique such as ICE endpoints must establish a communication channel through a NAT using
[I-D.ietf-mmusic-ice] or OUTBOUND [I-D.ietf-sip-outbound]. another technique. IETF has proposed standards including ICE
[I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for
establishing communication channels when a publicly accessible
rendezvous service is available.
This techniques available with this usage are powerful diagnostic
tools in the hands of a network administrator or system programmer
trying to determine the causes of network failure, in particular when
behavior varies by load, destination, or other factors that may be
related to NAT behavior.
This draft also proposes experimental applications of NAT Behavior
Discovery STUN for real-time selection of parameters for protocols in
situations where a publicly accessible rendezvous service is not
available. One such application is role selection in P2P networks
based on statistical experience with establishing connections and
diagnosing NAT behavior with a variety of peers. The experimental
question is whether such a test is useful. If a node trying to join
an overlay as a full peer when its NAT prevents sufficient
connectivity and then withdrawing is expensive or leads to unreliable
or poorly performing operation, then even if the behavior discovery
check is only "correct" 75% of the time, its relative cheapness may
make it very useful for optimizing the behavior of the overlay
network. Section 2.2 describes this experimental application in more
detail and discusses how to evaluate its success or failure.
The applications of this STUN usage are very different than the
original use of RFC3489 [RFC3489], which was intended for static
determination of device behavior. The NAT Behavior Discovery STUN
usage makes an explicit statement that it is not, and cannot be,
correct 100% of the time, but is still very useful. It is submitted
to the Internet community as an experimental protocol that, when
applied with appropriate statistical underpinnings and application
behavior that is ultimately based on experienced connectivity
patterns, can lead to more stability and increased performance than
is available without the knowledge it provides.
2. Introduction 2. Introduction
The Simple Traversal Underneath Network Address Translators (NAT) The Simple Traversal Underneath Network Address Translators (NAT)
(STUN) [I-D.ietf-behave-rfc3489bis] provides a mechanism to discover (STUN) [I-D.ietf-behave-rfc3489bis] provides a mechanism to discover
the reflexive transport address toward the STUN server, using the the reflexive transport address toward the STUN server, using the
Binding Request. This specification defines the NAT Behavior Binding Request. This specification defines the NAT Behavior
Discovery STUN usage, which allows a STUN client to probe the current Discovery STUN usage, which allows a STUN client to probe the current
behaviour of the NAT/FW devices between the client and the STUN behaviour of the NAT/FW devices between the client and the STUN
server. This usage defines new STUN attributes for the Binding server. This usage defines new STUN attributes for the Binding
skipping to change at page 4, line 37 skipping to change at page 5, line 25
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 behaviour 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 behaviour 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
behaviour and shorten the lifetime of new and existing bindings. In behaviour and shorten the lifetime of new and existing bindings. In
short, applications can discover how bad things currently are, but short, applications can discover how bad things currently are, but
not how bad things will get. not how bad things will get.
In principle, an application might base an adaptation decision based Despite this limitation, instantaneous observations are often quite
on the results of the Behavior Discovery usage. For example, a P2P
application could use some of these tests to deduce if it is a
reasonable supernode candidate, meaning that its NAT(s) offer(s)
Address Independent Filtering. It might periodically re-run tests
and would remove itself as a supernode if its NAT/FW chain lost this
characteristic. However, automatic adaptation based only on the
results of the Behavior Discovery usage may fail to account for its
inherent limitations in indicating only the current behavior of the
NAT(s) with regard to a particular destination address at a
particular instant in time. More importantly, it assumes the
application selects a STUN server that is appropriately located with
regards to its future communication partners. In general, an
application is unable to make such determinations. Consequently,
usage of the NAT Behavior Discovery STUN usage by applications to
select operating modes or optimizations is discouraged; only
experience with establishing connections with real communication
partners using a mechanism such as ICE or OUTBOUND can reliably
indicate the behavior an application will experience from the NAT.
Despite these limitations, 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. Diagnostic Use
Applications that work well in the lab, but fail in a deployment, are
notoriously common within distributed systems. There are few systems
developers who have not had the experience of searching to determine
the difference in the environments for insight as to what real-
network behavior was missed in the testing lab. The behavior
discovery usage offers a powerful tool that can be used to check NAT
and firewall behavior as the application is running.
As they are being used to detect instantaneous behavior for analysis
by an experienced developer or administrator, there are relatively
few concerns about this application of the NAT Behavior Discovery
STUN usage. However, the user should be aware that
o adding new traffic to new destinations (STUN servers) has the
potential to itself change the behavior of a NAT and
o the user must be careful to select a STUN server that is
appropriately located, ideally collocated (or even integrated)
with the communication partners of the application in question,
for the results to be applicable to the network conditions
experienced by the application.
2.2. Example Use with P2P Overlays
An application could use Behavior Discovery in a P2P protocol to
determine if a particular endpoint is a reasonable candidate to
participate as a peer or supernode (defined here as a peer in the
overlay that offers services, including message routing, to other
members or clients of the overlay network). This P2P network
application is willing to select supernodes that might be located
behind NATs to avoid the cost of dedicated servers. A supernode
candidate requires that its NAT(s) offer(s) Address Independent
Filtering. It might periodically re-run tests and would remove
itself as a supernode if its NAT/FW chain lost this characteristic.
These tests could be run with other supernode candidates acting as
STUN servers as well as dedicated STUN servers. As many P2P
algorithms tolerate non-transitive connectivity between a portion of
their peers, guaranteed pair-wise reliable reach might be sacrificed
in order to distribute the P2P overlay's load across peers that can
be directly contacted by the majority of users.
Use of Behavior Discovery for such an application requires:
o Specification of protocols capable of offering reliable end-user
performance using unreliable links between peers.
o The application is deployed behind NATs that provide Address
Independent Filtering and that remain in this mode for an amount
of time sufficient for the application to identify their behavior,
distribute this information to the rest of the overlay, and
provide useful work for the application.
This draft is experimental as deployed applications implementing open
protocols have yet to be deployed in such environments to demonstrate
that these two requirements have been met. However, apocryphal
evidence suggests that household- and small business-targeted NAT
devices have stable behaviour, especially when there are few clients
behind them. Numerous P2P applications have been deployed that
appear to have these properties, although their protocols have not
yet been subjected to rigorous evaluation by standards bodies.
2.3. Experimental Success
The criteria for an application to successfully demonstrate use of
the NAT Behavior Discovery STUN usage would include:
o An implementation that relies on this usage to determine its run-
time behavior, most likely using it to determine an initial choice
of options that are then adjusted based on experience with its
network connections.
o The implementation must either demonstrate its applicability in
environments where it is realistic to expect a provider to deploy
dedicated STUN servers with multiple IP addresses, or it must
demonstrate duplicating the behavior of such a dedicated STUN
server with two nodes that share the role of providing the
address-changing operations required by this usage.
o Experimental evidence that the application of this usage results
in improved behavior of the application in real-world conditions.
The exact metrics for this improvement may vary, some
possibilities include: faster convergence to the proper
parameters, less work to set up initial connections, fewer
reconfigurations required after startup, etc.
o A protocol specification that defines how the implementation
applies this usage.
The P2P scenario described above is a likely experimental test case
for this usage, but others applications are possible as well.
3. Overview of Operations 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 RFC3489 [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 RFC3489
skipping to change at page 6, line 5 skipping to change at page 8, line 16
A client behind a NAT wishes to determine if the NAT it is behind is A client behind a NAT wishes to determine if the NAT it is behind is
currently using independent, address dependent, or port dependent currently using independent, address dependent, or port dependent
mapping[RFC4787]. The client performs a series of tests that make mapping[RFC4787]. The client performs a series of tests that make
use of the OTHER-ADDRESS attribute; these tests are described in use of the OTHER-ADDRESS attribute; these tests are described in
detail in Section 4. These tests send binding requests to the detail in Section 4. These tests send binding requests to the
alternate address and port of the STUN server to determine mapping alternate address and port of the STUN server to determine mapping
behaviour. These tests can be used for UDP, TCP, or TCP/TLS behaviour. These tests can be used for UDP, TCP, or TCP/TLS
connections. connections.
This usage renames RFC3489's CHANGED-ADDRESS attribute to OTHER-
ADDRESS. Experience with 3489 indicated that many found use of
the word "changed" to be confusing. In all respects, OTHER-
ADDRESS is identical to CHANGED-ADDRESS, it is the same attribute
(including its attribute type number) with a new name.
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 the NAT it is behind is
currently using independent, address dependent, or port dependent currently using independent, address dependent, or port dependent
filtering[RFC4787]. The client performs a series of tests that make filtering[RFC4787]. The client performs a series of tests that make
use of the OTHER-ADDRESS and CHANGE-REQUEST attributes; these tests use of the OTHER-ADDRESS and CHANGE-REQUEST attributes; these tests
are described in Section 4. These tests request responses from the are described in Section 4. These tests request responses from the
alternate address and port of the STUN server; a precondition to alternate address and port of the STUN server; a precondition to
these tests is that no binding be established to the alternate these tests is that no binding be established to the alternate
address and port. Because the NAT does not know that the alternate address and port. Because the NAT does not know that the alternate
skipping to change at page 6, line 39 skipping to change at page 8, line 44
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.
Binding lifetime can be discovered by performing timed tests that use Binding lifetime can be discovered by performing timed tests that use
XOR-RESPONSE-ADDRESS. The client uses a second port and the STUN XOR-RESPONSE-TARGET. The client uses a second port and the STUN
server's alternate address to check if an existing binding that server's alternate address to check if an existing binding that
hasn't had traffic sent on it is still open after time T. This hasn't had traffic sent on it is still open after time T. This
approach is described in detail in Section 4.5. This test applies approach is described in detail in Section 4.5. This test applies
only to UDP datagrams. 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
skipping to change at page 7, line 20 skipping to change at page 9, line 29
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 which 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
XOR-RESPONSE-ADDRESS. XOR-RESPONSE-TARGET.
3.6. Detecting Generic ALGs 3.6. Detecting Generic ALGs
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 which
try to provide "generic" ALG functionality. These generic ALGs hunt try to provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This behavior can be detected 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 a NAT with a generic ALG in the path. not match, there is a NAT with a generic ALG in the path.
4. Discovery Process 4. Discovery Process
The NAT Behavior Discovery usage provides primitives that allow STUN The NAT Behavior Discovery usage provides primitives that allow STUN
checks to be made to determine the current behaviour of the NAT or checks to be made to determine the current behaviour of the NAT or
NATs an application is behind. These tests can only give the NATs an application is behind. These tests can only give the
instantaneous behaviour of a NAT; it has been found that NATs can instantaneous behaviour of a NAT; it has been found that NATs can
change behaviour under load and over time. An application must change behaviour under load and over time. An application must
assume that NAT behaviour can become more restrictive at any time. assume that NAT behaviour can become more restrictive at any time.
The tests described here are for UDP connectivity, NAT mapping The tests described here are for UDP connectivity, NAT mapping
skipping to change at page 9, line 22 skipping to change at page 11, line 30
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.2. An application requires only test I and II of Section 4.2. An application
determining its NAT does not always provide independent mapping might determining its NAT does not always provide independent mapping might
notify the user if no relay is configured, whereas an application notify the user if no relay is configured, whereas an application
behind a NAT that provides endpoint independent mapping might not behind a NAT that provides endpoint independent mapping might not
notify the user until a subsequent connection actually fails or might notify the user until a subsequent connection actually fails or might
provide a less urgent notification that no relay is configured. Such provide a less urgent notification that no relay is configured. Such
a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but
it does provide some information regarding whether ICE is likely to it does provide some information regarding whether ICE is likely to
be successful establishing connections. be successful establishing non-relayed connections.
Care must be taken when parallelizing tests, as some NAT devices have Care must be taken when parallelizing tests, as some NAT devices have
an upper limit on how quickly bindings will be allocated. an upper limit on how quickly bindings will be allocated.
4.5. Binding Lifetime Discovery 4.5. 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. For many NAT devices, an absolute refresh interval by the NAT. For many NAT devices, an absolute refresh interval
cannot be determined; bindings might be closed quicker under heavy cannot be determined; bindings might be closed quicker under heavy
load or might not behave as the tests suggest. For this reason load or might not behave as the tests suggest. For this reason
skipping to change at page 9, line 47 skipping to change at page 12, line 6
suggested refresh intervals. suggested refresh intervals.
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 socket, X. This creates a Request to the server from a particular socket, X. This creates a
binding in the NAT. The response from the server contains a MAPPED- binding in the NAT. The response from the server contains a MAPPED-
ADDRESS attribute, providing the public address and port on the NAT. ADDRESS attribute, providing the public address and port on the NAT.
Call this Pa and Pp, respectively. The client then starts a timer Call this Pa and Pp, respectively. The client then starts a timer
with a value of T seconds. When this timer fires, the client sends with a value of T seconds. When this timer fires, the client sends
another Binding Request to the server, using the same destination another Binding Request to the server, using the same destination
address and port, but from a different socket, Y. This request address and port, but from a different socket, Y. This request
contains an XOR-RESPONSE-ADDRESS address attribute, set to (Pa,Pp). contains an XOR-RESPONSE-TARGET address attribute, set to (Pa,Pp).
This will create a new binding on the NAT, and cause the STUN server This will create a new binding on the NAT, and cause the STUN server
to send a Binding Response that would match the old binding, if it to send a Binding Response that would match the old binding, if it
still exists. If the client receives the Binding Response on socket still exists. If the client receives the Binding Response on socket
X, it knows that the binding has not expired. If the client receives X, it knows that the binding has not expired. If the client receives
the Binding Response on socket Y (which is possible if the old the Binding Response on socket Y (which is possible if the old
binding expired, and the NAT allocated the same public address and binding expired, and the NAT allocated the same public address and
port to the new binding), or receives no response at all, it knows port to the new binding), or receives no response at all, it knows
that the binding has expired. that the binding has expired.
Because some NATs only refresh bindings when outbound traffic is Because some NATs only refresh bindings when outbound traffic is
skipping to change at page 10, line 23 skipping to change at page 12, line 31
is not received for any timer greater than T, but is received for any is not received for any timer greater than T, but is received for any
timer less than T. timer less than T.
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 than is
shorter than the actual one. For this reason, implementations are shorter than the actual one. Binding lifetime may also be dependent
on the traffic load on the NAT. For this reason, implementations are
encouraged to run the test numerous times and be prepared to get 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-behave-rfc3489bis]provides a response that confirms the [I-D.ietf-sip-outbound]provides a response that confirms the
connection is open and allows the client to check that its mapped connection is open and allows the client to check that its mapped
address has not changed. As that provides both the keepalive action address has not changed. As that provides both the keepalive action
and diagnostic that it is working, it should be preferred over any and diagnostic that it is working, it should be preferred over any
attempt to characterize the connection by a secondary technique. attempt to 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 [I-D.ietf-behave-rfc3489bis] are followed. Usage [I-D.ietf-behave-rfc3489bis] are followed.
If a client intends to utilize an XOR-RESPONSE-ADDRESS attribute in If a client intends to utilize an XOR-RESPONSE-TARGET attribute in
future transactions, as described in Section 4.5, then it MUST future transactions, as described in Section 4.5, then it MUST
include a CACHE-TIMEOUT attribute in the Request with the value set include a CACHE-TIMEOUT attribute in the Request with the value set
greater than the longest time duration it intends to test. The greater than the longest time duration it intends to test. The
server will also include this attribute in its Response, modified server will also include this attribute in its Response, modified
with its estimate of how long it will be able to cache this with its estimate of how long it will be able to cache this
connection. Because the returned value is only an estimate, the connection. Because the returned value is only an estimate, the
client must be prepared for the value to be wrong, and therefore to client must be prepared for the value to be wrong, and therefore to
receive a 430 response to its subsequent Requests with XOR-RESPONSE- receive a 481 response to its subsequent Requests with XOR-RESPONSE-
ADDRESS. TARGET.
OPEN ISSUE: is 430 the best approach to this (which should force the
client to get a new shared secret and retry the transaction) or
should a new return-type be used. Also, if shared secret is not
required, it's not at all appropriate.
Support for XOR-RESPONSE-ADDRESS is optional; it has a state cost on Support for XOR-RESPONSE-TARGET is optional due to the state cost on
the server and requires short-term credentials, which many the server. Therefore, a client MUST be prepared for receiving a 420
implementations don't support. Therefore, a client MUST be prepared (Unknown Attribute) error to requests that include XOR-RESPONSE-
for receiving a 420 (Unknown Attribute) error to requests that TARGET or CACHE-TIMEOUT. Support for OTHER-ADDRESS and CHANGE-
include XOR-RESPONSE-ADDRESS. Support for OTHER-ADDRESS and CHANGE-
REQUEST is optional, but MUST be supported by servers advertised via REQUEST is optional, but MUST be supported by servers advertised via
SRV, as described below. This is to allow the use of PADDING and SRV, as described below. This is to allow the use of PADDING and
XOR-RESPONSE-ADDRESS in P2P situations where peers do not have XOR-RESPONSE-TARGET in applications where servers do not have
multiple IP addresses. Clients MUST be prepared to receive a 420 for multiple IP addresses. Clients MUST be prepared to receive a 420 for
requests that include CHANGE-REQUEST when OTHER-ADDRESS was not requests that include CHANGE-REQUEST when OTHER-ADDRESS was not
received in Binding Response messages from the server. received in Binding Response messages from the server.
If an application makes use of the NAT Behavior Discovery STUN usage
by multiplexing it in a flow with application traffic, a FINGERPRINT
attribute SHOULD be included unless it is always possible to
distinguish a STUN message from an application message based on their
header.
Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response
unless they are using authentication with a provider of STUN servers
that is aware of the topology requirements of the tests being
performed.
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".
The protocol can be "udp", "tcp" or "tls". Other aspects of handling The protocol can be "udp", "tcp" or "tls". Other aspects of handling
failures and default ports are followed as described in STUN failures and default ports are followed as described in STUN
[I-D.ietf-behave-rfc3489bis]. [I-D.ietf-behave-rfc3489bis].
5.2. Security 5.2. Security
If the client is interested in performing a Binding Lifetime Servers MAY require authentication before allowing a client to make
Discovery test or other test requiring use of the XOR-RESPONSE- use of its services. This is particularly important to requests used
ADDRESS attribute, it MUST obtain a shared secret prior to beginning to perform a Binding Lifetime Discovery test or other test requiring
the test, and that shared secret must be used for all transactions use of the XOR-RESPONSE-TARGET attribute. The method for obtaining
during the test. If the client receives a 430 (Stale Credentials) these credentials, should the server require them, is outside the
Response to a Request containing a XOR-RESPONSE-ADDRESS, then it must scope of this usage. Presumably, the administrator or application
acquire a new short-term credential and begin the test again. relying on this usage should have its own method for obtaining
Procedures for obtaining a shared secret are described in STUN credentials. If the client receives a 401 (Unauthorized) Response to
[I-D.ietf-behave-rfc3489bis]. a Request, then it must either acquire the appropriate credential
from the application before retrying or report a permanent failure.
OPEN ISSUE: We would like to remove the MUST requirement for shared Procedures for encoding the MESSAGE-INTEGRITY attribute for a request
secret in favor of allowing servers to do rate limiting. are described in STUN [I-D.ietf-behave-rfc3489bis].
6. Server Behavior 6. Server Behavior
Unless otherwise specified here, all procedures for preparing, Unless otherwise specified here, all procedures for preparing,
sending, and processing messages as described for the STUN Binding sending, and processing messages as described for the STUN Binding
Usage of STUN [I-D.ietf-behave-rfc3489bis] are followed. Usage of STUN [I-D.ietf-behave-rfc3489bis] are followed.
A server implementing the NAT Behavior Discovery usage SHOULD be A server implementing the NAT Behavior Discovery usage SHOULD be
configured with two separate IP addresses on the public Internet. On configured with two separate IP addresses on the public Internet. On
startup, the server SHOULD allocate two UDP ports, such that it can startup, the server SHOULD allocate two UDP ports, such that it can
skipping to change at page 12, line 32 skipping to change at page 14, line 46
allocate the same ports on two different IP address, then it MUST NOT allocate the same ports on two different IP address, then it MUST NOT
include an OTHER-ADDRESS attribute in any Response and MUST respond include an OTHER-ADDRESS attribute in any Response and MUST respond
with a 420 (Unknown Attribute) to any Request with a CHANGE-REQUEST with a 420 (Unknown Attribute) to any Request with a CHANGE-REQUEST
attribute. A server with only one IP address MUST NOT be advertised attribute. A server with only one IP address MUST NOT be advertised
using the SRV service name "stun-behavior". using the SRV service name "stun-behavior".
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 server
begins processing specific to this Usage if the Request contains any begins processing specific to this Usage if the Request contains any
request attributes defined in this document: XOR-RESPONSE-ADDRESS, request attributes defined in this document: XOR-RESPONSE-TARGET,
CHANGE-REQUEST, or PADDING. If the Request does not contain any CHANGE-REQUEST, or PADDING. If the Request does not contain any
attributes from this document, OTHER-ADDRESS and SOURCE-ADDRESS are attributes from this document, OTHER-ADDRESS and RESPONSE-ORIGIN are
still included in the response as specified below. still included in the 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 CHANGE-REQUEST attribute and the server does
not have an alternate address and port as described above, the server not have an alternate address and port as described above, the server
MUST generate an error response of type 420. MUST generate an error response of type 420.
If the Request contains a CACHE-TIMEOUT attribute, then the server If the Request contains a CACHE-TIMEOUT attribute, then the server
SHOULD include a CACHE-TIMEOUT attribute in its response indicating SHOULD include a CACHE-TIMEOUT attribute in its response indicating
the duration (in seconds) it anticipates being able to cache this the duration (in seconds) it anticipates being able to cache this
binding request in anticipation of a future Request using the XOR- binding request in anticipation of a future Request using the XOR-
RESPONSE-ADDRESS attribute. The CACHE-TIMEOUT response value can be RESPONSE-TARGET attribute. The CACHE-TIMEOUT response value can be
greater or less than the value in the request. If the server is not greater or less than the value in the request. If the server is not
prepared to provide such an estimate, it SHOULD NOT include the prepared to provide such an estimate, it SHOULD NOT include the
CACHE-TIMEOUT attribute in its Response. CACHE-TIMEOUT attribute in its Response. The server SHOULD NOT
provide a CACHE-TIMEOUT length longer than the amount of time it has
been able to cache recent requests.
If the Request contains a XOR-RESPONSE-ADDRESS attribute, but the Because XOR-RESPONSE-TARGET offers the potential for minor
message does not contain a MESSAGE-INTEGRITY attribute and a indirection attacks, a server MUST either authenticate the users
USERNAME, the server MUST generate an error response of type 401. If requesting its use or rate-limit its response to those requests.
XOR-RESPONSE-ADDRESS is included, then the server must verify that it
has previously received a binding request from the same address as is If XOR-RESPONSE-TARGET is included in a Request, then the server must
specified in XOR-RESPONSE-ADDRESS. If it has not, or if sufficient verify that it has previously received a binding request from the
time has passed that it no longer has a record of having received same address as is specified in XOR-RESPONSE-TARGET. If it has not,
such a request due to limited state, it MUST respond with an error or if sufficient time has passed that it no longer has a record of
response of type 430. having received such a request due to limited state, it MUST respond
with an error response of type 481.
If the Request contains a XOR-RESPONSE-TARGET attribute and the
server is authenticating such requests, then the server checks the
message for a MESSAGE-INTEGRITY attribute and a USERNAME. If they
are not present the server MUST generate an error response of type
401.
If the Request contains a XOR-RESPONSE-TARGET attribute and the
server is rate-limiting such requests, it MUST ensure that it does
not generate a Response on a particular address more often than one
per second. If it receives requests more often than one per second,
it MUST generate a 503 (Service unavailable) Response to the Request.
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 the
Binding Request was received on, and are summarized in Table 1. Binding Request was received on, and are summarized in Table 1.
Let Da represent the destination IP address of the Binding Request Let Da represent the destination IP address of the Binding Request
(which will be either A1 or A2), and Dp represent the destination (which will be either A1 or A2), and Dp represent the destination
port of the Binding Request (which will be either P1 or P2). Let Ca port of the Binding Request (which will be either P1 or P2). Let Ca
represent the other address, so that if Da is A1, Ca is A2. If Da is represent the other address, so that if Da is A1, Ca is A2. If Da is
A2, Ca is A1. Similarly, let Cp represent the other port, so that if A2, Ca is A1. Similarly, let Cp represent the other port, so that if
skipping to change at page 13, line 51 skipping to change at page 16, line 31
+--------------------+----------------+-------------+---------------+ +--------------------+----------------+-------------+---------------+
| 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 SOURCE-ADDRESS 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.
OPEN ISSUE: 3489bis MUST allow SOURCE-ADDRESS and OTHER-ADDRESS in
any Binding Response, to allow 3489bis clients to use 3489 servers,
and to allow multiplexing of this usage on the same port of other
stun usages without adding a discovery mechanism. We decided that
this made sense for OTHER-ADDRESS in San Diego, but we forgot about
SOURCE-ADDRESS. This would be accomplished by adding SOURCE-ADDRESS
and OTHER-ADDRESS as known attributes to 3489bis...IANA registration
of the attributes would also move there.
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.
Next the server inspects the Request for a XOR-RESPONSE-ADDRESS Next the server inspects the Request for a XOR-RESPONSE-TARGET
attribute. If the XOR-RESPONSE-ADDRESS attribute is included, then attribute. If the XOR-RESPONSE-TARGET attribute is included, then it
it includes an XOR-REFLECTED-FROM attribute with the source address includes an XOR-REFLECTED-FROM attribute with the source address the
the Request was received from. Request was received from.
If the Request contained a PADDING attribute, then the server SHOULD If the Request contained a PADDING attribute, then the server SHOULD
insert a PADDING attribute of the same length into its response, but insert a PADDING attribute of the same length into its response, but
no longer than 64K. If the Request also contains the XOR-RESPONSE- no longer than 64K. If the Request also contains the XOR-RESPONSE-
ADDRESS attribute the server MUST return an error response of type TARGET attribute the server MUST return an error response of type
400. 400.
Following that, the server completes the remainder of the processing Following that, the server completes the remainder of the processing
from STUN [I-D.ietf-behave-rfc3489bis], including adding the SERVER, from STUN [I-D.ietf-behave-rfc3489bis]. The server MAY include a
MESSAGE-INTEGRITY, and FINGERPRINT attributes as appropriate. When SERVER attribute. If authentication is being required, the server
it sends the Response, it is sent from the source address as MUST include a MESSAGE-INTEGRITY and associated attributes as
determined above and to the destination address determined from the appropriate. A FINGERPRINT attribute is only required if the STUN
XOR-RESPONSE-ADDRESS, or to the source address of the Request if not messages are being multiplexed with application traffic that requires
specified. use of a FINGERPRINT to distinguish STUN messages. An ALTERNATE-
SERVER attribute SHOULD NOT be included.
When the server sends the Response, it is sent from the source
address as determined above and to the destination address determined
from the XOR-RESPONSE-TARGET, or to the source address of the Request
otherwise.
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. The majority of these Binding Requests and Binding Responses. CHANGE-REQUEST was
attributes were originally defined in RFC3489 [RFC3489], but are originally defined in RFC3489 [RFC3489] but is redefined here as that
redefined here as that document is obsoleted by RFC3489bis document is obsoleted by RFC3489bis [I-D.ietf-behave-rfc3489bis].
[I-D.ietf-behave-rfc3489bis].
Comprehension-required range (0x0000-0x7FFF):
0x0003: CHANGE-REQUEST 0x0003: CHANGE-REQUEST
0x0004: SOURCE-ADDRESS 0x0026: PADDING
0x0005: OTHER-ADDRESS 0x0027: XOR-RESPONSE-TARGET
0x0023: XOR-REFLECTED-FROM 0x0028: XOR-REFLECTED-FROM
0x0027: XOR-RESPONSE-ADDRESS
0x8026: PADDING Comprehension-optional range (0x8000-0xFFFF)
0x8027: CACHE-TIMEOUT 0x8027: CACHE-TIMEOUT
0x802b: RESPONSE-ORIGIN
0x802c: OTHER-ADDRESS
7.1. Representing Transport Addresses 7.1. Representing Transport Addresses
Whenever an attribute contains a transport address, it has the same Whenever an attribute contains a transport address, it has the same
format as MAPPED-ADDRESS. Similarly, the XOR- attributes have the format as MAPPED-ADDRESS. Similarly, the XOR- attributes have the
same format as XOR-MAPPED-ADDRESS[I-D.ietf-behave-rfc3489bis]. same format as XOR-MAPPED-ADDRESS[I-D.ietf-behave-rfc3489bis].
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
skipping to change at page 16, line 5 skipping to change at page 18, line 26
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
the Binding Request was received on. the Binding Request was received on.
B: This is the "change port" flag. If true, it requests the server B: This is the "change port" flag. If true, it requests the server
to send the Binding Response with a different port than the one to send the Binding Response with a different port than the one
the Binding Request was received on. the Binding Request was received on.
7.3. SOURCE-ADDRESS 7.3. RESPONSE-ORIGIN
The SOURCE-ADDRESS attribute is inserted by the server and indicates The RESPONSE-ORIGIN attribute is inserted by the server and indicates
the source IP address and port the response was sent from. It is the source IP address and port the response was sent from. It is
useful for detecting twice NAT configurations. It is only present in useful for detecting twice NAT configurations. It is only present in
Binding Responses. Binding Responses.
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 as CHANGED-ADDRESS from RFC3489 OTHER-ADDRESS uses the same attribute as CHANGED-ADDRESS from RFC3489
because it is simply a new name with the same semantics as CHANGED- because it is simply a new name with the same semantics as CHANGED-
ADDRESS. It has been renamed to more clearly indicate its function. ADDRESS. It has been renamed to more clearly indicate its function.
7.5. XOR-REFLECTED-FROM 7.5. XOR-REFLECTED-FROM
The XOR-REFLECTED-FROM attribute is present only in Binding Responses The XOR-REFLECTED-FROM attribute is present only in Binding Responses
when the Binding Request contained a XOR-RESPONSE-ADDRESS attribute. when the Binding Request contained a XOR-RESPONSE-TARGET attribute.
The attribute contains the transport address of the source where the The attribute contains the transport address of the source where the
request came from. Its purpose is to provide traceability, so that a request came from. Its purpose is to provide traceability, so that a
STUN server cannot be used as a reflector for anonymous denial-of- STUN server cannot be used as a reflector for anonymous denial-of-
service attacks. service attacks.
The XOR-REFLECTED-FROM attribute is used in place of RFC3489's The XOR-REFLECTED-FROM attribute is used in place of RFC3489's
REFLECTED-FROM attribute. It provides the same information, but REFLECTED-FROM attribute. It provides the same information, but
because the NAT's public address is obfuscated through the XOR because the NAT's public address is obfuscated through the XOR
function, It can pass through a NAT that would otherwise attempt to function, It can pass through a NAT that would otherwise attempt to
translate it to the private network address. translate it to the private network address.
7.6. XOR-RESPONSE-ADDRESS 7.6. XOR-RESPONSE-TARGET
The XOR-RESPONSE-ADDRESS attribute contains an IP address and port. The XOR-RESPONSE-TARGET attribute contains an IP address and port.
The XOR-RESPONSE-ADDRESS attribute can be present in the Binding The XOR-RESPONSE-TARGET attribute can be present in the Binding
Request and indicates where the Binding Response is to be sent. When Request and indicates where the Binding Response is to be sent. When
not present, the server sends the Binding Response to the source IP not present, the server sends the Binding Response to the source IP
address and port of the Binding Request. The server MUST NOT process address and port of the Binding Request. The server MUST NOT process
a request containing a XOR-RESPONSE-ADDRESS that does not contain a request containing a XOR-RESPONSE-TARGET that does not contain
MESSAGE-INTEGRITY. The XOR-RESPONSE-ADDRESS attribute is optional in MESSAGE-INTEGRITY. The XOR-RESPONSE-TARGET attribute is optional in
the Binding Request. the Binding Request.
XOR-RESPONSE-ADDRESS is used in place of RFC3489's RESPONSE-ADDRESS. XOR-RESPONSE-TARGET is used in place of RFC3489's RESPONSE-ADDRESS.
It provides the same information, but because the NAT's public It provides the same information, but because the NAT's public
address is obfuscated through the XOR function, It can pass through a address is obfuscated through the XOR function, It can pass through a
NAT that would otherwise attempt to translate it to the private NAT that would otherwise attempt to translate it to the private
network address. network address.
7.7. PADDING 7.7. 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 freeform string, the value of which does not
skipping to change at page 17, line 33 skipping to change at page 20, line 11
PADDING MUST be no longer than 64K and SHOULD be an even multiple of PADDING MUST be no longer than 64K and SHOULD be an even multiple of
four bytes. four bytes.
7.8. CACHE-TIMEOUT 7.8. CACHE-TIMEOUT
The CACHE-TIMEOUT is used in Binding Requests and Responses. It The CACHE-TIMEOUT is used in Binding Requests and Responses. It
indicates the time duration (in seconds) that the server will cache indicates the time duration (in seconds) that the server will cache
the source address and USERNAME of an original binding request that the source address and USERNAME of an original binding request that
will later by followed by a request from a different source address will later by followed by a request from a different source address
with a XOR-RESPONSE-ADDRESS asking that a response be reflected to with a XOR-RESPONSE-TARGET asking that a response be reflected to the
the source address of the original binding request. A server SHOULD source address of the original binding request. A server SHOULD NOT
NOT send a response to a target address requested with XOR-RESPONSE- send a response to a target address requested with XOR-RESPONSE-
ADDRESS unless it has cached that the same USERNAME made a previous TARGET unless it has cached that the same USERNAME made a previous
binding request from that target address. The client inserts a value binding request from that target address. The client inserts a value
in CACHE-TIMEOUT into the Binding Request indicating the amount of in CACHE-TIMEOUT into the Binding Request indicating the amount of
time it would like the server to cache that information. The server time it would like the server to cache that information. The server
responds with a CACHE-TIMEOUT in its Binding Response providing a responds with a CACHE-TIMEOUT in its Binding Response providing a
prediction of how long it will cache that information. The response prediction of how long it will cache that information. The response
value can be greater than, equal to, or less than the requested value can be greater than, equal to, or less than the requested
value. If the server is not able to provide such an estimate or the value. If the server is not able to provide such an estimate or the
information in the response would be meaningless, the server should information in the response would be meaningless, the server should
not include a CACHE-TIMEOUT attribute in its response. not include a CACHE-TIMEOUT attribute in its response.
8. IAB Considerations 8. New Response Codes
This draft defines new STUN response code.
8.1. 481 Connection does not exist
This code is generated when a server has received an XOR-RESPONSE-
TARGET, but the server has no record of having received a prior
binding Request from the address specified in XOR-RESPONSE-TARGET.
The client should re-submit the original binding request with an
appropriate CACHE-TIMEOUT attribute. If the server's response
includes a CACHE-TIMEOUT that is shorter than the client's request,
the server is unable to satisfy the caching time requested by the
client and the client SHOULD NOT continue to retry the request.
8.2. 503 Service Unavailable
This response is generated when a server receives Requests specifying
a particular address in their XOR-RESPONSE-TARGET attribute more
often than one per second.
9. IAB Considerations
The IAB has studied the problem of ``Unilateral Self Address The IAB has studied the problem of ``Unilateral Self Address
Fixing'', which is the general process by which a client attempts to Fixing'', which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT 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 RFC 3424
[RFC3424]. The STUN NAT Behavior Discovery usage is an example of a [RFC3424]. The STUN NAT Behavior Discovery usage is an example of a
protocol that performs this type of function. The IAB has mandated protocol that performs this type of function. The IAB has mandated
that any protocols developed for this purpose document a specific set that any protocols developed for this purpose document a specific set
of considerations. This section meets those requirements. of considerations. This section meets those requirements.
8.1. Problem Definition 9.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; this is why "short term fixes
usually aren't". usually aren't".
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 characteristics of that NAT in order to either to determine the instantaneous characteristics of that NAT in order
diagnose the cause of problems experienced by that or other to either diagnose the cause of problems experienced by that or other
applications or for an application to modify its behavior based on applications or for an application to modify its behavior based on
the current behavior of the NAT. the current behavior of the NAT and an appropriate statistical model
of the behavior required for the application to succeed.
8.2. Exit Strategy 9.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. Instead, that is provided by other protocols. strategy. Instead, that is provided by other initiatives. Work is
Specifically, the Interactive Connectivity Establishment (ICE) currently proceeding on proposals for protocols that allow clients to
[I-D.ietf-mmusic-ice] mechanism allows two cooperating clients to determine the location of and control the behavior of NATs through
interactively determine the best addresses to use when communicating, direct interaction with the NAT; Nat Control STUN Usage
regardless of the type of NAT involved. BEHAVE is currently [I-D.wing-behave-nat-control-stun-usage] STUN NAT Behavior Discovery
considering proposals for protocols that allow clients to determine is no longer needed once NATs that can be communicated with directly
the location of and control the behavior of NATs through direct are in use. Finally, as NATs phase out and as IPv6 is deployed, STUN
interaction with the NAT. STUN NAT Behavior Discovery is no longer NAT Behavior Discovery will no longer be of any interest.
needed once NATs that can be communicated with directly are in use.
Finally, as NATs phase out and as IPv6 is deployed, STUN NAT Behavior
Discovery will no longer be of any interest.
8.3. Brittleness Introduced by STUN NAT Behavior Discovery 9.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. While this can be according to the current behavior of the NAT. This draft is
helpful in improving the performance of an application, an improperly experimental because the extent to which brittleness is introduced to
written application could use information from this usage and assume an application relying on the Behavior Discovery usage is unclear and
that the NAT will always behave in the same manner, and thus failing must be carefully evaluated by the designers of the protocol making
to work properly when the NAT changes its behavior. Regardless of use of it. The experimental test for this protocol is essentially
whether an application makes use of NAT Behavior Discovery or not, if determining whether an application can be made less brittle through
it does not use techniques such as ICE [I-D.ietf-mmusic-ice] or the use of behavior-discovery information than it would be if
OUTBOUND [I-D.ietf-sip-outbound] it exposes itself to the inherent attempted to make use of the network without any awareness of the
instability of NAT. NATs its traffic must pass through.
8.4. Requirements for a Long Term Solution 9.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.
Our experience with STUN NAT Behavior Discovery continues to validate As long as NATs are present, means of adapting to their presence will
our belief in the requirements outlined in Section 14.4 of STUN be required. Direct control or discovery of NATs by applications,
[I-D.ietf-behave-rfc3489bis]. such as proposed in Nat Control STUN Usage
[I-D.wing-behave-nat-control-stun-usage], will eliminate the need for
anonymous diagnostics of NAT behavior.
8.5. Issues with Existing NAPT Boxes 9.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 NA[P]Ts and experience reports.
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 which
try and provide "generic" ALG functionality. These generic ALGs hunt try and provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This usage avoids that problem rewrite them if they match a binding. This usage avoids that problem
by using the XOR-REFLECTED-FROM and XOR-RESPONSE-ADDRESS attributes by using the XOR-REFLECTED-FROM and XOR-RESPONSE-TARGET attributes
instead of the older REFLECTED-FROM and RESPONSE-ADDRESS attributes. instead of the older REFLECTED-FROM and RESPONSE-ADDRESS attributes.
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 10. IANA Considerations
This specification defines several new STUN attributes. This section This specification defines several new STUN attributes. This section
directs IANA to add these new protocol elements to the IANA registry directs IANA to add these new protocol elements to the IANA registry
of STUN protocol elements. The code for OTHER-ADDRESS renames this of STUN protocol elements.
code from CHANGED-ADDRESS to OTHER-ADDRESS for clarity, the semantics
remain the same.
OPEN ISSUE: does IANA consider these new attributes or are they in OPEN ISSUE: does IANA consider CHANGE-REQUEST a new attribute or is
forever from original 3489? it forever from original 3489?
0x0003: CHANGE-REQUEST 0x0003: CHANGE-REQUEST
0x0004: SOURCE-ADDRESS 0x0027: XOR-RESPONSE-TARGET
0x0005: OTHER-ADDRESS 0x0028: XOR-REFLECTED-FROM
0x0023: XOR-REFLECTED-FROM
0x0027: XOR-RESPONSE-ADDRESS
0x0026: PADDING 0x0026: PADDING
0x8026: CACHE-TIMEOUT 0x8027: CACHE-TIMEOUT
0x802b: RESPONSE-ORIGIN
0x802c: OTHER-ADDRESS
10. Security Considerations This specification defines two new STUN error response codes.
481: Connection does not exist
503: Service Unavailable
11. Security Considerations
This usage inherits the security considerations of STUN This usage inherits the security considerations of STUN
[I-D.ietf-behave-rfc3489bis]. This usage adds several new [I-D.ietf-behave-rfc3489bis]. This usage adds several new
attributes; security considerations for those are detailed here. attributes; security considerations for 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 Request can completely hide the STUN server compromise the Binding Request can completely hide the STUN server
from the client. from the client.
XOR-RESPONSE-ADDRESS allows a STUN server to be used as a reflector XOR-RESPONSE-TARGET allows a STUN server to be used as a reflector
for denial-of-service attacks. The XOR-REFLECTED-FROM mitigates this for denial-of-service attacks. It does not provide any amplification
by providing the identity (in terms of IP address) of the source of the attack. The XOR-REFLECTED-FROM mitigates this by providing
where the request came from. Its purpose is to provide traceability, the identity (in terms of IP address) of the source where the request
so that a STUN server cannot be used as an anonymous reflector for came from. Its purpose is to provide traceability, so that a STUN
denial-of-service attacks. Authenticating the XOR-RESPONSE-ADDRESS server cannot be used as an anonymous reflector for denial-of-service
using shared secrets alleviates this threat. Server caching previous attacks. XOR-RESPONSE-TARGET is rate-limited or uses pre-existing
contacts before directing a response to a XOR-RESPONSE-ADDRESS credentials to alleviate this threat. Server caching previous
further eliminates the threat, although it introduces the complexity contacts before directing a response to a XOR-RESPONSE-TARGET further
of state into a STUN server. CACHE-TIMEOUT is used to reduce the eliminates the threat, although it introduces the complexity of state
amount of additional state required. into a STUN server. CACHE-TIMEOUT is used to reduce the amount of
additional state required.
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 which 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.
11. Open Issues CHANGE-REQUEST provides no attacks, but adds three more reflection
sources for the XOR-RESPONSE-TARGET reflection attacks. It provides
no additional amplification and the security mechanisms for XOR-
RESPONSE-TARGET are deemed sufficient.
In Section 5: Use 430 for CACHE-TIMEOUT errors or introduce a new RESPONSE-ORIGIN, CACHE-TIMEOUT and XOR-REFLECTED-FROM do not provide
error code? any additional attacks.
In Section 6.1 need to confirm final solution for 3489bis clients to 12. Open Issues
not error out on responses with SOURCE-ADDRESS and OTHER-ADDRESS.
Does IANA consider attributes that were in 3489 but not in 3489bis to Does IANA consider attributes that were in 3489 but not in 3489bis to
have been removed from the registry and should be re-registered by have been removed from the registry and should be re-registered by
this document, or are there forever in the registry from 3489? this document, or are there forever in the registry from 3489?
We would like to remove the MUST requirement for shared secret when 13. Acknowledgements
used with XOR-RESPONSE-ADDRESS in favor of allowing servers to do
rate limiting.
12. 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
specification [RFC3489] from which many of the ideas, attributes, and specification [RFC3489] from which many of the ideas, attributes, and
description in this document originated. description in this document originated.
13. References 14. References
13.1. Normative References 14.1. Normative References
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
Wing, "Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-07 (work in progress), draft-ietf-behave-rfc3489bis-12 (work in progress),
July 2007. November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[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.
13.2. Informative References 14.2. Informative References
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-16 (work in progress), June 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-09 (work in progress), June 2007. draft-ietf-sip-outbound-10 (work in progress), July 2007.
[I-D.wing-behave-nat-control-stun-usage]
Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering,
Querying, and Controlling Firewalls and NATs",
draft-wing-behave-nat-control-stun-usage-05 (work in
progress), October 2007.
[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 Appendix A. Change Log
RFC-EDITOR: Please remove this entire Change Log section while RFC-EDITOR: Please remove this entire Change Log section while
formatting this document for publication. formatting this document for publication.
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00
o Only OTHER-ADDRESS, CHANGE-ADDRESS, and XOR-RESPONSE-ADDRESS o Only OTHER-ADDRESS, CHANGE-ADDRESS, and XOR-RESPONSE-TARGET
support is optional; support for PADDING and SOURCE-ADDRESS is now support is optional; support for PADDING and SOURCE-ADDRESS is now
mandatory mandatory
o PADDING is now a mandatory attribute o PADDING is now a mandatory attribute
o OTHER-ADDRESS is returned in all binding responses if the server o OTHER-ADDRESS is returned in all binding responses if the server
has a second IP address has a second IP address
A.2. from draft-ietf-behave-nat-behavior-discovery-00 A.2. from draft-ietf-behave-nat-behavior-discovery-00
o Clarified that only servers with two IP addresses should have an o Clarified that only servers with two IP addresses should have an
SRV entry SRV entry
o Removed support for backward compatibility with 3489 clients by o Removed support for backward compatibility with 3489 clients by
removing non-XOR forms of attributes. Language states that removing non-XOR forms of attributes. Language states that
backward compatiblity with 3489 clients is SHOULD NOT. backward compatibility with 3489 clients is SHOULD NOT.
Compatibility with 3489 servers is left unspecified. Compatibility with 3489 servers is left unspecified.
o PADDING is mandatory and language has been changed to indicate o PADDING is mandatory and language has been changed to indicate
that if a server supports PADDING it must either actually provide 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 the padding or return an error (can't support it but refuse to do
it) it)
o Require both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS to be returned o Require both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS to be returned
to support detection of generic ALGs 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.
Authors' Addresses Authors' Addresses
Derek C. MacDonald Derek C. MacDonald
CounterPath Solutions, Inc. CounterPath Solutions, Inc.
Suite 300, One Bentall Centre, 505 Burrard St Suite 300, One Bentall Centre, 505 Burrard St
Vancouver, BC V7X1M3 Vancouver, BC V7X1M3
Canada Canada
Phone: +1-604-320-3344 Phone: +1-604-320-3344
Email: derek@counterpath.com Email: derek@counterpath.com
 End of changes. 77 change blocks. 
258 lines changed or deleted 439 lines changed or added

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