RFC Errata
Found 4 records.
Status: Verified (1)
RFC 5780, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", May 2010
Note: This RFC has been updated by RFC 8553
Source of RFC: behave (tsv)
Errata ID: 2844
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: John Selbie
Date Reported: 2011-06-25
Verifier Name: Wes Eddy
Date Verified: 2011-06-27
Section 7.5 says:
RESPONSE-PORT is a 16-bit unsigned integer in network byte order followed by 2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65536.
It should say:
RESPONSE-PORT is a 16-bit unsigned integer in network byte order followed by 2 bytes of padding. Allowable values of RESPONSE-PORT are 0-65535.
Notes:
The 16-bit unsigned int range is 0-65535 (0x0000 - 0xffff). 65536 can't be represented inside a a 16-bit.
Status: Reported (1)
RFC 5780, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", May 2010
Note: This RFC has been updated by RFC 8553
Source of RFC: behave (tsv)
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.
Status: Held for Document Update (2)
RFC 5780, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", May 2010
Note: This RFC has been updated by RFC 8553
Source of RFC: behave (tsv)
Errata ID: 2939
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: John Selbie
Date Reported: 2011-08-17
Held for Document Update by: Wes Eddy
Date Held: 2012-04-27
Section 9.1 says:
Section 9.1 ... 0x802c: OTHER-ADDRESS
Notes:
The document contradicts itself, one place (section 7.4) saying that OTHER-ADDRESS has the same value as CHANGED-ADDRESS did, and the other place (section 9.1) giving a new value, which matches the IANA registry. The statement explaining why it has the same value (which it doesn't) should be removed.
Errata ID: 4327
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Xinbang Hu
Date Reported: 2015-04-03
Held for Document Update by: Spencer Dawkins
Date Held: 2016-01-13
Section 3.6 says:
This test apples to UDP and TCP, but not TLS over TCP connections.
It should say:
This test applies to UDP and TCP, but not TLS over TCP connections.
Notes:
"apples" should be "applies".