|
1.
|
Clear description of the referenced document:
|
|
|
|
Name:
|
IETF RFC 3489 (2003)
|
|
Title:
|
STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
|
|
|
2.
|
Status of approval:
|
|
|
Standards track RFC, though now made obsolete
|
|
3.
|
Justification for the specific reference:
|
|
|
The procedures in H.460.24 depend heavily on the protocol defined in this RFC. While there are known issues with ill-behaved NAT devices, as explained under point (6) below, this Recommendation assumes the use of a well-behaved NAT device and is not recommended for use otherwise. Although this RFC has been made obsolete by the IETF, it is widely implemented by SIP, XMPP, and other communication systems.
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3489
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
This was published as a Standards Track RFC in 2003. It has been oboleted by RFC 5389 (Oct 2008).
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
The protocol has been widely deployed and there are multiple interoperable versions demonstrated. While the IETF obsoleted this RFC, it was done so due to the fact that some NAT devices do not behave consistently and predictably. As a consequence, the IETF decided to deprecate the RFC in favor of one that essentially requires "guesses" or dependence on a media proxy. At the same time, NAT/FW vendors were made aware of the issues with inconsistent behavior and have worked to address the problem.
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
Superseded by RFC 5389 (Oct 2008).
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative References/
/
[1] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997./
/
[2] Dierks, T. and C. Allen, "The TLS protocol Version 1.0", RFC 2246, January 1999./
/
[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000./
/
[4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002./
/
[5] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000./
/
[6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981./
/
[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000./
/
Informative References/
/
[8] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002./
/
[9] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox Communication Architecture and Framework", RFC 3303, August 2002./
/
[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002./
/
[11] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001./
/
[12] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996./
/
[13] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997./
/
[14] Kohl, J. and C. Neuman, "The kerberos Network Authentication Service (V5)", RFC 1510, September 1993./
/
[15] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999./
/
[16] Baugher M., et al., "The secure real-time transport protocol", Work in Progress./
/
[17] Daigle, L., Editor, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002./
/
[18] Huitema, C., "RTCP attribute in SDP", Work in Progress.
|
|
9.
|
Qualification of
ISOC/IETF:
|
|
|
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).
9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.
9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
|
|
10.
|
Other (for any supplementary information):
|
|
|
N/A
|
|
