STUN协议RFC5389：NAT穿越实用工具标准

需积分: 15 168 浏览量更新于2024-07-15 收藏 76KB PDF 举报

STUN协议RFC5389是网络工作组由J. Rosenberg领导的一项重要标准文档，于2008年10月发布。该协议旨在为因特网上处理网络地址转换(NAT)穿越问题的其他协议提供一种实用工具。STUN的主要功能包括帮助客户端确定通过NAT分配给它的IP地址和端口，这对于支持在线通信的实时应用至关重要，如VoIP和多媒体会议系统。 STUN的核心作用在于辅助NAT穿透，它并不直接提供NAT穿越解决方案，而是作为解决方案的一部分被集成。通过发送STUN请求，一个设备能够检查与另一端点的连接是否畅通，并确认其NAT映射的状态。这有助于确保数据包能够正确路由到目标，即使在NAT设备背后，避免了常见的NAT相关问题，如NAT障壁（NAT Traversal）和隐藏节点问题（Hidden Node Problem）。 STUN协议设计时考虑了广泛的NAT类型，包括静态NAT、动态NAT和PAT（Port Address Translation），因此它能够在大多数类型的NAT环境中正常运作，无需对NAT设备进行特殊配置或修改。它也支持作为一种保持NAT绑定状态的机制，这对于维持长连接和实时通信的可靠性非常重要。此外，RFC5389规定，该文档作为互联网标准跟踪协议，公开讨论并欢迎改进意见。读者可以参考互联网官方协议标准（STD 1）获取关于STUN协议最新版本的标准化状态和更新信息。该文档的分发不受限制，意味着所有网络管理员和开发人员都可以查阅和使用STUN协议来优化他们的网络服务和应用程序。总结来说，STUN协议RFC5389是一个基础且实用的网络技术，对于构建可扩展、可靠和兼容NAT环境的现代互联网服务至关重要。它为开发者提供了一套标准化的方法来检测、管理和维护跨NAT通信，是提高互联网服务质量不可或缺的一部分。

RFC 5389 STUN October 2008

Reflexive Transport Address: A transport address learned by a client

that identifies that client as seen by another host on an IP

network, typically a STUN server. When there is an intervening

NAT between the client and the other host, the reflexive transport

address represents the mapped address allocated to the client on

the public side of the NAT. Reflexive transport addresses are

learned from the mapped address attribute (MAPPED-ADDRESS or XOR-

MAPPED-ADDRESS) in STUN responses.

Mapped Address: Same meaning as reflexive address. This term is

retained only for historic reasons and due to the naming of the

MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes.

Long-Term Credential: A username and associated password that

represent a shared secret between client and server. Long-term

credentials are generally granted to the client when a subscriber

enrolls in a service and persist until the subscriber leaves the

service or explicitly changes the credential.

Long-Term Password: The password from a long-term credential.

Short-Term Credential: A temporary username and associated password

that represent a shared secret between client and server. Short-

term credentials are obtained through some kind of protocol

mechanism between the client and server, preceding the STUN

exchange. A short-term credential has an explicit temporal scope,

which may be based on a specific amount of time (such as 5

minutes) or on an event (such as termination of a SIP dialog).

The specific scope of a short-term credential is defined by the

application usage.

Short-Term Password: The password component of a short-term

credential.

STUN Indication: A STUN message that does not receive a response.

Attribute: The STUN term for a Type-Length-Value (TLV) object that

can be added to a STUN message. Attributes are divided into two

types: comprehension-required and comprehension-optional. STUN

agents can safely ignore comprehension-optional attributes they

don’t understand, but cannot successfully process a message if it

contains comprehension-required attributes that are not

understood.

RTO: Retransmission TimeOut, which defines the initial period of

time between transmission of a request and the first retransmit of

that request.

Rosenberg, et al. Standards Track [Page 9]

RFC 5389 STUN October 2008

6. STUN Message Structure

STUN messages are encoded in binary using network-oriented format

(most significant byte or octet first, also commonly known as big-

endian). The transmission order is described in detail in Appendix B

of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are

in decimal (base 10).

All STUN messages MUST start with a 20-byte header followed by zero

or more Attributes. The STUN header contains a STUN message type,

magic cookie, transaction ID, and message length.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|0 0| STUN Message Type | Message Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Magic Cookie |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| |

| Transaction ID (96 bits) |

| |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Format of STUN Message Header

The most significant 2 bits of every STUN message MUST be zeroes.

This can be used to differentiate STUN packets from other protocols

when STUN is multiplexed with other protocols on the same port.

The message type defines the message class (request, success

response, failure response, or indication) and the message method

(the primary function) of the STUN message. Although there are four

message classes, there are only two types of transactions in STUN:

request/response transactions (which consist of a request message and

a response message) and indication transactions (which consist of a

single indication message). Response classes are split into error

and success responses to aid in quickly processing the STUN message.

Rosenberg, et al. Standards Track [Page 10]

RFC 5389 STUN October 2008

The message type field is decomposed further into the following

structure:

0 1

2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+-+-+-+-+-+-+-+-+-+-+-+-+

|M |M |M|M|M|C|M|M|M|C|M|M|M|M|

|11|10|9|8|7|1|6|5|4|0|3|2|1|0|

+--+--+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Format of STUN Message Type Field

Here the bits in the message type field are shown as most significant

(M11) through least significant (M0). M11 through M0 represent a 12-

bit encoding of the method. C1 and C0 represent a 2-bit encoding of

the class. A class of 0b00 is a request, a class of 0b01 is an

indication, a class of 0b10 is a success response, and a class of

0b11 is an error response. This specification defines a single

method, Binding. The method and class are orthogonal, so that for

each method, a request, success response, error response, and

indication are possible for that method. Extensions defining new

methods MUST indicate which classes are permitted for that method.

For example, a Binding request has class=0b00 (request) and

method=0b000000000001 (Binding) and is encoded into the first 16 bits

as 0x0001. A Binding response has class=0b10 (success response) and

method=0b000000000001, and is encoded into the first 16 bits as

0x0101.

Note: This unfortunate encoding is due to assignment of values in

[RFC3489] that did not consider encoding Indications, Success, and

Errors using bit fields.

The magic cookie field MUST contain the fixed value 0x2112A442 in

network byte order. In RFC 3489 [RFC3489], this field was part of

the transaction ID; placing the magic cookie in this location allows

a server to detect if the client will understand certain attributes

that were added in this revised specification. In addition, it aids

in distinguishing STUN packets from packets of other protocols when

STUN is multiplexed with those other protocols on the same port.

The transaction ID is a 96-bit identifier, used to uniquely identify

STUN transactions. For request/response transactions, the

transaction ID is chosen by the STUN client for the request and

echoed by the server in the response. For indications, it is chosen

by the agent sending the indication. It primarily serves to

correlate requests with responses, though it also plays a small role

Rosenberg, et al. Standards Track [Page 11]

剩余50页未读，继续阅读

LIEYz

粉丝: 54
资源: 22

STUN协议RFC5389：NAT穿越实用工具标准

STUN-RFC5389中英文合集.zip

stun:快速的RFC 5389 STUN实现

RFC5389 中文版

STUN_RFC3489.pdf

stun_RFC5389_中文

STUN 协议RFC3489中文版 只要5积分

RFC3489.zip_RFC3489

STUN-RFC3489中英文合集.zip

STUN协议详解：RFC5389中文版关键内容概览

RFC5389中文版：STUN协议详解与安全策略

最新资源

STUN 协议RFC3489中文版只要5积分