RFC 5780, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", May 2010

Note: This RFC has been updated by RFC 8553

Errata ID: 7971
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Forest
Date Reported: 2024-06-05

Section 4.4 says:

This will also require at most three tests.

[...]

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.

It should say:

This will require at most four tests.

[...]

If the client receives a response, the current behavior is
Address-Dependent Filtering.

If no response is received, test IV must be performed to distinguish
between Address and Port-Dependent Filtering and lack of connectivity
with the STUN server's alternate address.  For example, a server
might be configured with a private OTHER-ADDRESS or reside behind an
interfering firewall.  In test IV, the client sends a Binding Request
(without a CHANGE-REQUEST attribute) to the alternate address, but
primary port.  If the client receives a response, the current
behavior is Address and Port-Dependent Filtering; if no response is
received, the client knows that it does not have UDP connectivity
with the server's alternate address, and therefore cannot use the
current server to determine the current filtering behavior.

Notes:

I am suggesting this change after encountering several public STUN
servers with an OTHER-ADDRESS (or CHANGED-ADDRESS) set to 0.0.0.0,
10.x.x.x, 172.x.x.x, or 192.168.x.x. With such a server, a client
following this RFC as currently written (version 08) will incorrectly
assume it has discovered Address and Port-Dependent Filtering.

I would also note in section 4.5 (Combining and Ordering Tests) that
filtering behavior test IV is the same as the mapping behavior test
II, allowing them to be combined so long as the filtering tests are
done before the mapping tests (to preserve prior NAT state).

In support of that ordering, I would ideally have this RFC present
the filtering tests before presenting the mapping tests, by swapping
section 4.4 with 4.3 and swapping 3.2 with 3.1. This would make
things easier for people implementing the spec, as they would
intuitively follow the optimal ordering simply by following the RFC's
presented order, and would no longer have to mentally reorder the
written steps whenever validating or reasoning about their code.
Swapping those sections would, of course, affect external references
to those section numbers; I don't know if that would too disruptive a
change without assigning a new RFC number.

Report New Errata