-
Notifications
You must be signed in to change notification settings - Fork 6
/
rfc5780.txt
executable file
·1515 lines (1070 loc) · 66.2 KB
/
rfc5780.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Internet Engineering Task Force (IETF) D. MacDonald
Request for Comments: 5780 B. Lowekamp
Category: Experimental Skype
ISSN: 2070-1721 May 2010
NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
Abstract
This specification defines an experimental usage of the Session
Traversal Utilities for NAT (STUN) Protocol that discovers the
presence and current behavior of NATs and firewalls between the STUN
client and the STUN server.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5780.
MacDonald & Lowekamp Experimental [Page 1]
RFC 5780 NAT Behavior Discovery May 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
MacDonald & Lowekamp Experimental [Page 2]
RFC 5780 NAT Behavior Discovery May 2010
Table of Contents
1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 6
2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7
2.3. Experimental Goals . . . . . . . . . . . . . . . . . . . . 8
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 9
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 10
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 10
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 11
3.6. Detecting a Generic Application Level Gateway (ALG) . . . 11
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 12
4.2. Checking for UDP Connectivity with the STUN Server . . . . 13
4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14
4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 14
4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15
4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 15
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 18
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Representing Transport Addresses . . . . . . . . . . . . . 21
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 21
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22
7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 22
7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 23
8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 23
8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 24
8.4. Requirements for a Long-Term Solution . . . . . . . . . . 24
8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 25
9.2. Port Numbers and SRV Registry . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 27
MacDonald & Lowekamp Experimental [Page 3]
RFC 5780 NAT Behavior Discovery May 2010
1. Applicability
This experimental NAT Behavior Discovery STUN usage provides
information about a NAT device's observable transient behavior; it
determines a NAT's behavior with regard to the STUN server used and
the particular client ports used at the instant the test is run.
This STUN usage does not allow an application behind a NAT to make an
absolute determination of the NAT's characteristics. NAT devices do
not behave consistently enough to predict future behavior with any
guarantee. Applications requiring reliable reach between two
particular endpoints must establish a communication channel through
NAT using another technique. IETF has proposed standards including
[RFC5245] and [RFC5626] for establishing communication channels when
a publicly accessible rendezvous service is available.
The uses envisioned for the STUN attributes included in this document
are diagnostics and real-time tuning of applications. For example,
determining what may work and should be tried first compared to more
expensive methods. The attributes can also be used to observe
behaviors that causes an application's communication to fail, thus
enabling better selection of methods of recovery. The STUN
attributes could also be a basis for a network technician's
diagnostics tool to observe NAT behavior.
This document proposes experimental usage of these attributes for
real-time optimization of parameters for protocols in situations
where a publicly accessible rendezvous service is not available.
Such a use of these techniques is only possible when the results are
applied as an optimization and a reliable fallback is available in
case the NAT's behavior becomes more restrictive than determined by
the Behavior Discovery tests. One possible application is role
selection in peer-to-peer (P2P) networks based on statistical
experience with establishing direct connections and diagnosing NAT
behavior with a variety of peers. The experimental question is
whether such a test is useful. Consider a node that tries to join an
overlay as a full peer when its NAT prevents sufficient connectivity;
joining and withdrawing from the overlay might be expensive and/or
lead to unreliable or poorly performing operations. Even if the
behavior discovery check is only "correct" 75% of the time, its
relative cheapness may make it very useful for optimizing the
behavior of the overlay network. Section 2.2 describes this
experimental application in more detail and discusses how to evaluate
its success or failure.
The applications of this STUN usage differ from the original use of
STUN (originally RFC 3489 [RFC3489], now RFC 5389 [RFC5389]). This
specification acknowledges that the information gathered in this
MacDonald & Lowekamp Experimental [Page 4]
RFC 5780 NAT Behavior Discovery May 2010
usage is not, and cannot be, correct 100% of the time, whereas STUN
focused only on getting information that could be known to be correct
and static.
This specification can also be compared to ICE. ICE requires a
fallback to TURN be available whereas RFC 3489 based applications
tried to determine in advance whether they would need a relay and
what their peer reflexive address will be, which is not generally
achievable.
This STUN usage requires an application using it to have a fallback.
However, unlike ICE's focus on the problems inherent in VoIP
sessions, this STUN usage doesn't assume that it will be used to
establish a connection between a single pair of machines, so
alternative fallback mechanisms may be available.
For example, in a P2P application it may be possible to simply switch
out of the role where such connections need to be established or to
select an alternative indirect route if the peer discovers that, in
practice, 10% of its connection attempts fail.
It is submitted to the Internet community as an experimental protocol
that, when applied with appropriate statistical underpinnings and
application behavior that is ultimately based on experienced
connectivity patterns, can lead to more stability and increased
performance than is available without the knowledge it provides.
If a Standards Track document specifies the use of any portion of
this STUN usage, that document MUST describe how incorrect
information derived using these methods will be managed, either
through identifying when a NAT's behavior changed or because the
protocol uses such knowledge as an optimization but remains
functional when the NAT's behavior changes. The referencing document
MUST also define when the fallback mechanism will be invoked.
Applications in different domains may vary greatly in how
aggressively the fallback mechanism is utilized, so there must be a
clear definition of when the fallback mechanism is invoked.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
MacDonald & Lowekamp Experimental [Page 5]
RFC 5780 NAT Behavior Discovery May 2010
2. Introduction
"Session Traversal Utilities for NAT (STUN)" [RFC5389] provides a
mechanism to discover the reflexive transport address toward the STUN
server, using the Binding Request. This specification defines the
NAT Behavior Discovery STUN usage, which allows a STUN client to
probe the current behavior of the NAT/firewall (NAT/FW) devices
between the client and the STUN server. This usage defines new STUN
attributes for the Binding Request and Binding Response.
Many NAT/FW devices do not behave consistently and will change their
behavior under load and over time. Applications requiring high
reliability must be prepared for the NAT's behavior to become more
restrictive. Specifically, it has been found that under load NATs
may transition to the most restrictive filtering and mapping behavior
and shorten the lifetime of new and existing bindings. In short,
applications can discover how bad things currently are, but not how
bad things will get.
Despite this limitation, instantaneous observations are often quite
useful in troubleshooting network problems, and repeated tests over
time, or in known load situations, may be used to characterize a
NAT's behavior. In particular, in the hands of a person
knowledgeable about the needs of an application and the nodes an
application needs to communicate with, it can be a powerful tool.
2.1. Example Diagnostic Use
Applications that work well in the lab, but fail in a deployment, are
notoriously common within distributed systems. There are few systems
developers who have not had the experience of searching to determine
the difference in the environments for insight as to what real-
network behavior was missed in the testing lab. The Behavior
Discovery usage offers a powerful tool that can be used to check NAT
and firewall behavior as the application is running. For example, an
application could be designed to perform Behavior Discovery tests
whenever it experiences significant communications problems when
running. Such analysis might be included as part of the diagnostic
information logged by the application.
As they are being used to detect instantaneous behavior for analysis
by an experienced developer or administrator, there are relatively
few concerns about this application of the NAT Behavior Discovery
STUN usage. However, the user should be aware that
o adding new traffic to new destinations (STUN servers) has the
potential to itself change the behavior of a NAT and
MacDonald & Lowekamp Experimental [Page 6]
RFC 5780 NAT Behavior Discovery May 2010
o the user must be careful to select a STUN server that is
appropriately located, ideally collocated (or even integrated)
with the communication partners of the application in question,
for the results to be applicable to the network conditions
experienced by the application.
2.2. Example Use with P2P Overlays
An application could use Behavior Discovery in a P2P protocol to
determine if a particular endpoint is a reasonable candidate to
participate as a peer or supernode (defined here as a peer in the
overlay that offers services, including message routing, to other
members or clients of the overlay network). This P2P network
application is willing to select supernodes that might be located
behind NATs to avoid the cost of dedicated servers. A supernode
candidate requires that its NAT or NATs offer Endpoint-Independent
Filtering. It might periodically re-run tests and would remove
itself as a supernode if its NAT/FW chain lost this characteristic.
These tests could be run with other supernodes acting as STUN servers
as well as with dedicated STUN servers. As many P2P algorithms
tolerate non-transitive connectivity between a portion of their
peers, guaranteed pair-wise reliable reach might be sacrificed in
order to distribute the P2P overlay's load across peers that can be
directly contacted by the majority of users.
Consider an example from a hypothetical P2P protocol in more detail:
when P2P node A starts up, it tests its NAT(s) relative to other
peers already in the overlay. If the results of its testing indicate
A is behind a "good" NAT (with Endpoint-Independent Mapping and
Filtering), A will join the overlay and establish connections with
appropriate peers in the overlay to join the overlay's topology.
Although A is reachable by routing messages across the overlay
topology, A will also include in its communication with other nodes
that they may reach it directly using its reflexive IP address (or
addresses) that A discovered in its initial testing. Suppose that
later, node B wants to send a message to A, and B is not a neighbor
of A in the overlay topology. B may send the message directly to A's
IP address and start a timer. If B doesn't receive a response within
a certain amount of time, then it routes the message to A across the
overlay instead and includes a flag that indicates a direct
connection was attempted but failed. (Alternatively, B could
simultaneously send the message to A's IP address across the overlay,
which guarantees minimum response latency, but can waste bandwidth.)
Over time, A observes the percentage of successful direct messages it
receives out of those attempted. If the percentage of successful
direct connections is below some threshold (perhaps 75%), then A may
stop advertising for direct connections because it has determined in
practice that its NATs are not providing sufficiently reliable
MacDonald & Lowekamp Experimental [Page 7]
RFC 5780 NAT Behavior Discovery May 2010
connectivity to justify the cost of attempting the direct message.
But if the percentage is high enough, A continues to advertise
because the successful direct connections are improving the overlay's
performance by reducing the routing load imposed on the overlay. If
at some point, A's NAT or NATs change behavior, A will notice a
change in its percentage of successful direct connections and may re-
evaluate its decision to advertise a public address. In this
hypothetical example, behavior discovery is used for A's initial
operating mode selection, but the actual decision for whether to
continue advertising that public IP/port pair is made based on actual
operating data. The results of the Behavior Discovery usage are also
used as a performance optimization, as A is at all times able to
establish connectivity through the overlay if the attempted direct
connection fails.
Use of behavior discovery for such an application requires:
o Use of a protocol capable of offering reliable end-user
performance while using unreliable links between pairs of nodes.
o A protocol offering a reliable fallback to connections attempted
based on the results of Behavior Discovery probing.
o The application is deployed behind NATs that provide Endpoint-
Independent Filtering and that remain in this mode for an amount
of time sufficient for the application to identify their behavior,
distribute this information to the rest of the overlay, and
provide useful work for the application.
This document is experimental as applications implementing open
protocols have yet to be deployed in such environments to demonstrate
that these three requirements have been met. However, anecdotal
evidence suggests that NATs targeted at households and small
businesses have stable behavior, especially when there are few
clients behind them. Numerous P2P applications have been deployed
that appear to have these properties, although their protocols have
not yet been subjected to rigorous evaluation by standards bodies.
2.3. Experimental Goals
The criteria for an application to successfully demonstrate use of
the NAT Behavior Discovery STUN usage would include:
o An implementation that relies on this usage to determine its run-
time behavior, most likely using it to determine an initial choice
of options that are then adjusted based on experience with its
network connections.
MacDonald & Lowekamp Experimental [Page 8]
RFC 5780 NAT Behavior Discovery May 2010
o The implementation must either demonstrate its applicability in
environments where it is realistic to expect a provider to deploy
dedicated STUN servers with multiple IP addresses, or it must
demonstrate duplicating the behavior of such a dedicated STUN
server with two nodes that share the role of providing the
address-changing operations required by this usage.
o Experimental evidence that the application of this usage results
in improved behavior of the application in real-world conditions.
The exact metrics for this improvement may vary, some
possibilities include: faster convergence to the proper
parameters, less work to set up initial connections, fewer
reconfigurations required after startup, etc.
o A protocol specification that defines how the implementation
applies this usage.
The P2P scenario described above is a likely experimental test case
for this usage, but others applications are possible as well.
3. Overview of Operations
In a typical configuration, a STUN client is connected to a private
network and through one or more NATs to the public Internet. The
client is configured with the address of a STUN server on the public
Internet. The Behavior Discovery usage makes use of SRV records so
that a server may use a different transport address for this usage
than for other usages. This usage does not provide backward
compatibility with RFC 3489 [RFC3489] for either clients or servers.
Implementors of clients that wish to be compliant with RFC 3489
servers should see that specification. Implementors of servers
SHOULD NOT include support for RFC 3489 clients, as the original uses
of that protocol have been deprecated.
Because STUN forbids a server from creating a new TCP or TCP/TLS
connection to the client, many tests apply only to UDP. The
applicability of the various tests is indicated below.
The STUN NAT Behavior Discovery usage defines new attributes on the
STUN Binding Request and STUN Binding Response that allow these
messages to be used to diagnose the current behavior of the NAT(s)
between the client and server.
This section provides a descriptive overview of the typical use of
these attributes. Normative behavior is described in Sections 5, 6,
and 7.
MacDonald & Lowekamp Experimental [Page 9]
RFC 5780 NAT Behavior Discovery May 2010
3.1. Determining NAT Mapping
A client behind a NAT wishes to determine if that NAT is currently
using Endpoint-Independent, Address-Dependent, or Address and Port-
Dependent Mapping [RFC4787]. The client performs a series of tests
that make use of the OTHER-ADDRESS attribute; these tests are
described in detail in Section 4. These tests send binding requests
to the alternate address and port of the STUN server to determine
mapping behavior. These tests can be used for UDP, TCP, or TCP/TLS
connections.
3.2. Determining NAT Filtering
A client behind a NAT wishes to determine if that NAT is currently
using Endpoint-Independent, Address-Dependent, or Address and Port-
Dependent Filtering [RFC4787]. The client performs a series of tests
that make use of the OTHER-ADDRESS and CHANGE-REQUEST attributes;
these tests are described in Section 4. These tests request
responses from the alternate address and port of the STUN server; a
precondition to these tests is that no binding be established to the
alternate address and port. See below for more information. Because
the NAT does not know that the alternate address and port belong to
the same server as the primary address and port, it treats these
responses the same as it would those from any other host on the
Internet. Therefore, the success of the binding responses sent from
the alternate address and port indicate whether the NAT is currently
performing Endpoint-Independent Filtering, Address-Dependent
Filtering, or Address and Port-Dependent Filtering. This test
applies only to UDP datagrams.
3.3. Binding Lifetime Discovery
Many systems, such as VoIP, rely on being able to keep a connection
open between a client and server or between peers of a P2P system.
Because NAT bindings expire over time, keepalive messages must be
sent across the connection to preserve it. Because keepalives impose
some overhead on the network and servers, reducing the frequency of
keepalives can be useful.
A normal request-response protocol cannot be used to test binding
lifetime because the initial request resets the binding timer.
Behavior discovery defines the RESPONSE-PORT attribute to allow the
client and server to set up a "control channel" using one port on the
client that is used to test the binding lifetime of a different port
allocated on the client. More generally, RESPONSE-PORT allows the
client to allocate two ports and request that responses to queries
sent from one port be delivered to the other. The client uses its
second port and the STUN server's alternate address to check if an
MacDonald & Lowekamp Experimental [Page 10]
RFC 5780 NAT Behavior Discovery May 2010
existing binding that hasn't had traffic sent on it is still open
after time T. This approach is described in detail in Section 4.6.
This test applies only to UDP datagrams.
3.4. Diagnosing NAT Hairpinning
STUN Binding Requests allow a client to determine whether it is
behind a NAT that supports hairpinning of connections. To perform
this test, the client first sends a Binding Request to its STUN
server to determine its mapped address. The client then sends a STUN
Binding Request to this mapped address from a different port. If the
client receives its own request, the NAT hairpins connections. This
test applies to UDP, TCP, or TCP/TLS connections.
3.5. Determining Fragment Handling
Some NATs exhibit different behavior when forwarding fragments than
when forwarding a single-frame datagram. In particular, some NATs do
not hairpin fragments at all and some platforms discard fragments
under load. To diagnose this behavior, STUN messages may be sent
with the PADDING attribute, which simply inserts additional space
into the message. By forcing the STUN message to be divided into
multiple fragments, the NAT's behavior can be observed.
All of the previous tests can be performed with PADDING if a NAT's
fragment behavior is important for an application, or only those
tests that are most interesting to the application can be retested.
PADDING only applies to UDP datagrams. PADDING can not be used with
RESPONSE-PORT.
3.6. Detecting a Generic Application Level Gateway (ALG)
A number of NAT boxes are now being deployed into the market that try
to provide "generic" ALG functionality. These generic ALGs hunt for
IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This behavior can be detected
because the STUN server returns both the MAPPED-ADDRESS and XOR-
MAPPED-ADDRESS in the same response. If the result in the two does
not match, there is a NAT with a generic ALG in the path. This test
apples to UDP and TCP, but not TLS over TCP connections.
4. Discovery Process
This section provides a descriptive overview of how the NAT Behavior
Discovery usage primitives allow checks to be made to discover the
current behavior of the NAT or NATs an application is behind. These
tests can only give the instantaneous behavior of a NAT; it has been
found that NATs can change behavior under load and over time. The
MacDonald & Lowekamp Experimental [Page 11]
RFC 5780 NAT Behavior Discovery May 2010
results of these tests therefore can be regarded as upper bounds --
an application must assume that NAT behavior can become more
restrictive at any time. Results from tests performed using a
particular port on the client may also not indicate the behavior
experienced by a different port, as described in Section 4.1.
Definitions for NAT filtering and mapping behavior are from
[RFC4787]. The tests described here are for UDP connectivity, NAT
mapping behavior, NAT filtering behavior, and NAT binding lifetime
discovery; additional tests could be designed using this usage's
mechanisms. The tests described below include only tests that can be
performed using a client with a single IP address. A client with
multiple IP addresses (or multiple clients collaborating) behind the
same NAT can combine their probes to test additional aspects of NAT
behavior, such as port overloading. This section provides a
descriptive overview of how the primitives provided by the STUN
attributes in this specification may be used to perform behavior
tests.
Normative specifications for the attributes are defined in later
sections.
4.1. Source Port Selection
Proper source port selection is important to ensuring the usefulness
and accuracy of the Behavior Discovery tests. There are two
preconditions for tests:
o Because mapping behavior can vary on a port-by-port basis, an
application should perform its tests using the source port
intended for use by the application whenever possible. If it
intends to use multiple source ports, it should repeat these tests
for each source port. Such tests should be performed sequentially
to reduce load on the NAT.
o Because the results of some diagnostic checks depend on previous
state in the NAT created by prior traffic, the tests should be
performed using a source port that has not generated recent
traffic. Therefore, the application should use a random source
port or ensure that no traffic has previously occurred on the
selected port prior to performing tests, generally by allocating a
port and holding it unused for at least 15 minutes prior to the
tests.
Ensuring both of these preconditions can be challenging, particularly
for a device or application wishing to perform Behavior Discovery
tests at startup. The following guidelines are suggested for
reducing the likelihood of problems:
MacDonald & Lowekamp Experimental [Page 12]
RFC 5780 NAT Behavior Discovery May 2010
o An application intended to operate behind a NAT should not attempt
to allocate a specific or well-known port. Because such software
must be designed to interoperate using whatever port is mapped to
it by the NAT, the specific port is unnecessary. Instead, on
startup, a random port should be selected (see below for
recommended ranges). An application, particularly on an embedded
device, should not rely on the host operating system to select the
next available port because that might result in the application
receiving the same port on each restart. An application using the
same port between restarts may not receive accurate results from
Behavior Discovery tests that are intended to test state-related
behavior of NATs, such as filtering and binding lifetime.
o An application requiring multiple ports, such as separate ports
for control and media, should allocate those ports on startup when
possible. Even if there is no immediate need for media flow, if
Behavior Discovery tests will be run on those ports, allocating
them early will allow them to be left idle, increasing the chance
of obtaining accurate results from Behavior Discovery tests.
o Although the most reliable results are obtained when performing
tests with the specific ports that the application will use, in
many cases an application will need to allocate and use ports
without being able to perform complete Behavior Discovery tests on
those ports. In those cases, an application should randomly
select its ports from a range likely to receive the same treatment
by the NAT. This document recommends ranges of 32768-49151, which
is the upper end of IANA's Registered Ports range, and 49152-
65535, which is IANA's Dynamic and/or Private port range, for
random selection. To attempt to characterize a NAT's general
treatment of ports in these ranges, a small number of ports within
a range can be randomly selected and characterized.
Those tests particularly sensitive to prior state on a NAT will be
indicated below.
4.2. Checking for UDP Connectivity with the STUN Server
The client sends a STUN Binding Request to a server. This causes the
server to send the response back to the address and port that the
request came from. If this test yields no response, the client knows
right away that it does not have UDP connectivity with the STUN
server. This test requires only STUN [RFC5389] functionality.
MacDonald & Lowekamp Experimental [Page 13]
RFC 5780 NAT Behavior Discovery May 2010
4.3. Determining NAT Mapping Behavior
This will require at most three tests. In test I, the client
performs the UDP connectivity test. The server will return its
alternate address and port in OTHER-ADDRESS in the binding response.
If OTHER-ADDRESS is not returned, the server does not support this
usage and this test cannot be run. The client examines the XOR-
MAPPED-ADDRESS attribute. If this address and port are the same as
the local IP address and port of the socket used to send the request,
the client knows that it is not NATed and the effective mapping will
be Endpoint-Independent.
In test II, the client sends a Binding Request to the alternate
address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding
Response is the same as test I the NAT currently has Endpoint-
Independent Mapping. If not, test III is performed: the client sends
a Binding Request to the alternate address and port. If the XOR-
MAPPED-ADDRESS matches test II, the NAT currently has Address-
Dependent Mapping; if it doesn't match it currently has Address and
Port-Dependent Mapping.
4.4. Determining NAT Filtering Behavior
This will also require at most three tests. These tests are
sensitive to prior state on the NAT.
In test I, the client performs the UDP connectivity test. The server
will return its alternate address and port in OTHER-ADDRESS in the
binding response. If OTHER-ADDRESS is not returned, the server does
not support this usage and this test cannot be run.
In test II, the client sends a binding request to the primary address
of the server with the CHANGE-REQUEST attribute set to change-port
and change-IP. This will cause the server to send its response from
its alternate IP address and alternate port. If the client receives
a response, the current behavior of the NAT is Endpoint-Independent
Filtering.
If no response is received, test III must be performed to distinguish
between Address-Dependent Filtering and Address and Port-Dependent
Filtering. In test III, the client sends a binding request to the
original server address with CHANGE-REQUEST set to change-port. If
the client receives a response, the current behavior is Address-
Dependent Filtering; if no response is received, the current behavior
is Address and Port-Dependent Filtering.
MacDonald & Lowekamp Experimental [Page 14]
RFC 5780 NAT Behavior Discovery May 2010
4.5. Combining and Ordering Tests
Clients may wish to combine and parallelize these tests to reduce the
number of packets sent and speed the discovery process. For example,
test I of the filtering and mapping tests also checks if UDP is
blocked. Furthermore, an application or user may not need as much
detail as these sample tests provide. For example, establishing
connectivity between nodes becomes significantly more difficult if a
NAT has any behavior other than Endpoint-Independent Mapping, which
requires only test I and II of Section 4.3. An application that
determines its NAT does not always provide Endpoint-Independent
Mapping might notify the user if no relay is configured, whereas an
application behind a NAT that provides Endpoint-Independent Mapping
might not notify the user until a subsequent connection actually
fails or might provide a less urgent notification that no relay is
configured. Such a test does not alleviate the need for [RFC5245],
but it does provide some information regarding whether ICE is likely
to be successful establishing non-relayed connections.
Care must be taken when combining and parallelizing tests, due to the
sensitivity of certain tests to prior state on the NAT and because
some NAT devices have an upper limit on how quickly bindings will be
allocated. Section 5 restricts the rate at which clients may begin
new STUN transactions.
4.6. Binding Lifetime Discovery
STUN can also be used to probe the lifetimes of the bindings created
by the NAT. Such tests are sensitive to prior state on the NAT. For
many NAT devices, an absolute refresh interval cannot be determined;
bindings might be closed more quickly under heavy load or might not
behave as the tests suggest. For this reason, applications that
require reliable bindings must send keepalives as frequently as
required by all NAT devices that will be encountered. Suggested
refresh intervals are outside the scope of this document. [RFC5245]
and OUTBOUND [RFC5626] have suggested refresh intervals.
Determining the binding lifetime relies on two separate source ports
being used to send STUN Binding Requests to the STUN server. The
general approach is that the client uses a source port X to send a
single Binding Request. After a period of time during which source
port X is not used, the client uses a second source port Y to send a
Binding Request to the STUN server that indicates the response should
be sent to the binding established to port X. If the binding for
port X has timed out, that response will not be received. By varying
the time between the original Binding Request sent from X and the
subsequent request sent from Y, the client can determine the binding
lifetime.
MacDonald & Lowekamp Experimental [Page 15]
RFC 5780 NAT Behavior Discovery May 2010
To determine the binding lifetime, the client first sends a Binding
Request to the server from a particular source port, X. This creates
a binding in the NAT. The response from the server contains a
MAPPED-ADDRESS attribute, providing the public address and port on
the NAT. Call this Pa and Pp, respectively. The client then starts
a timer with a value of T seconds. When this timer fires, the client
sends another Binding Request to the server, using the same
destination address and port, but from a different source port, Y.
This request contains an RESPONSE-PORT attribute, set to Pp, to
request the response be delivered to (Pa, Pp). This will create a
new binding on the NAT, and cause the STUN server to send a Binding
Response that would match the old binding, (Pa, Pp), if it still
exists. If the client receives the Binding Response on port X, it
knows that the binding has not expired. If the client receives the
Binding Response on port Y (which is possible if the old binding
expired, and the NAT allocated the same public address and port to
the new binding), or receives no response at all, it knows that the
binding has expired.
Because some NATs only refresh bindings when outbound traffic is
sent, the client must resend a binding request from the original
source port before beginning a second test with a different value of
T. The client can find the value of the binding lifetime by doing a
binary search through T, arriving eventually at the value where the
response is not received for any timer greater than T, but is
received for any timer less than T. Note also that the binding
refresh behavior (outbound only or all traffic) can be determined by
sending multiple Binding Requests from port Y without refreshes from
the original source port X.
This discovery process takes quite a bit of time and is something
that will typically be run in the background on a device once it
boots.
It is possible that the client can get inconsistent results each time
this process is run. For example, if the NAT should reboot, or be
reset for some reason, the process may discover a lifetime that is
shorter than the actual one. Binding lifetime may also be dependent
on the traffic load on the NAT. For this reason, implementations are
encouraged to run the test numerous times and be prepared to get
inconsistent results.
Like the other diagnostics, this test is inherently unstable. In
particular, an overloaded NAT might reduce binding lifetime to shed
load. A client might find this diagnostic useful at startup, for
example, setting the initial keepalive interval on its connection to
the server to 10 seconds while beginning this check. After
determining the current lifetime, the keepalive interval used by the
MacDonald & Lowekamp Experimental [Page 16]
RFC 5780 NAT Behavior Discovery May 2010
connection to the server can be set to this appropriate value.
Subsequent checks of the binding lifetime can then be performed using
the keepalives in the server connection. The STUN Keepalive Usage
[RFC5626] provides a response that confirms the connection is open
and allows the client to check that its mapped address has not
changed. As that provides both the keepalive action and diagnostic
that it is working, it should be preferred over any attempt to
characterize the connection by a secondary technique.
5. Client Behavior
Unless otherwise specified here, all procedures for preparing,
sending, and processing messages as described in the STUN Binding
Usage [RFC5389] are followed.
As support for RESPONSE-PORT is optional, a client MUST be prepared
to receive a 420 (Unknown Attribute) error to requests that include
RESPONSE-PORT. Support for OTHER-ADDRESS and CHANGE-REQUEST is
optional, but MUST be supported by servers advertised via SRV, as
described below. This is to allow the use of PADDING and RESPONSE-
PORT in applications where servers do not have multiple IP addresses.
Clients MUST be prepared to receive a 420 for requests that include
CHANGE-REQUEST when OTHER-ADDRESS was not received in Binding
Response messages from the server.
If an application makes use of the NAT Behavior Discovery STUN usage
by multiplexing it in a flow with application traffic, a FINGERPRINT
attribute SHOULD be included unless it is always possible to
distinguish a STUN message from an application message based on their
header.
When PADDING is used, it SHOULD be equal to the MTU of the outgoing
interface.
Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response
unless they are using authentication with a provider of STUN servers
that is aware of the topology requirements of the tests being
performed.
A client SHOULD NOT generate more than ten new STUN transactions per
second and SHOULD pace them such that the retransmission timeouts
(RTOs) do not synchronize the retransmissions of each transaction.
5.1. Discovery
Unless the user or application is aware of the transport address of a
STUN server supporting the NAT Behavior Discovery usage through other
means, a client is configured with the domain name of the provider of
MacDonald & Lowekamp Experimental [Page 17]
RFC 5780 NAT Behavior Discovery May 2010
the STUN servers. The domain is resolved to a transport address
using SRV procedures [RFC2782]. The mechanism for configuring the
client with the domain name of the STUN servers or of acquiring a
specific transport address is out of scope for this document.
For the Behavior Discovery usage, the service name is "stun-behavior"
for UDP and TCP. The service name is "stun-behaviors" for TLS over
TCP. Only "tcp" is defined as a protocol for "stun-behaviors".
Other aspects of handling failures and default ports are followed as
described in STUN [RFC5389].
5.2. Security
Servers MAY require authentication before allowing a client to make
use of its services. The method for obtaining these credentials,
should the server require them, is outside the scope of this usage.
Presumably, the administrator or application relying on this usage
should have its own method for obtaining credentials. If the client
receives a 401 (Unauthorized) Response to a Request, then it must
either acquire the appropriate credential from the application before
retrying or report a permanent failure. Procedures for encoding the
MESSAGE-INTEGRITY attribute for a request are described in STUN
[RFC5389].
6. Server Behavior
Unless otherwise specified here, all procedures for preparing,
sending, and processing messages as described for the STUN Binding
Usage of STUN [RFC5389] are followed.
A server implementing the NAT Behavior Discovery usage SHOULD be
configured with two separate IP addresses on the public Internet. On
startup, the server SHOULD allocate a pair of ports for each of the
UDP, TCP, and TCP/TLS transport protocols, such that it can send and
receive datagrams using the same ports on each IP address (normally a
wildcard binding accomplishes this). TCP and TCP/TLS MUST use
different ports. If a server cannot allocate the same ports on two
different IP address, then it MUST NOT include an OTHER-ADDRESS
attribute in any Response and MUST respond with a 420 (Unknown
Attribute) to any Request with a CHANGE-REQUEST attribute. A server
with only one IP address MUST NOT be advertised using the SRV service
name "stun-behavior" or "stun-behaviors".