RFC5389_CN
1.简介 (3)
2.源于RFC3489的演变 (3)
3.操作概览 (4)
4.术语 (5)
5.定义 (5)
6. STUN消息结构 (6)
7.基本的协议处理 (8)
7.1形成一个请求消息或一个指示消息 (8)
7.2发送请求消息或者指示消息 (8)
7.2.1通过UDP发送 (9)
7.2.2通过TCP或者TCP上的TLS发送 (9)
7.3接受一个STUN消息 (10)
7.3.1处理一个请求 (11)
7.3.2处理一个指示 (12)
7.3.4处理一个错误响应 (13)
8. FINGERPRINT机制 (13)
9. server的DNS发现 (13)
10.鉴权和消息完整性机制 (14)
10.1短期证书机制 (14)
10.1.1形成一个请求或者指示 (15)
10.1.2接受一个请求或指示 (15)
10.1.3接受一个响应 (15)
10.2长期证书机制 (15)
10.2.1形成一个请求 (16)
10.2.2接受一个请求 (16)
10.2.3接受一个请求 (17)
11.ALTERNATE-SERVER机制 (17)
12.向后兼容RFC3489 (18)
12.1client处理的改变 (18)
12.2server处理的改变 (18)
13.基本server行为 (19)
14. STUN 用法 (19)
15. STUN 属性 (20)
15.1MAPPED-ADDRESS (20)
15.2 XOR-MAPPED-ADDRESS (21)
15.3USERNAME (22)
15.5FINGERPRINT (23)
15.6ERROR-CODE (23)
15.7域 (24)
15.8 NONCE (25)
15.9未知属性 (25)
15.10软件 (25)
15.11 ALTERNA TE-SERVER (26)
16.安全考虑 (26)
16.1针对协议的攻击 (26)
16.1.1外围攻击 (26)
16.1.2内部攻击 (26)
16.2影响用法的攻击 (27)
16.2.1攻击I：针对目标的分布式Dos(Ddos) (27)
16.2.2攻击II：隐藏客户端 (27)
16.2.3 攻击III：假冒client的身份 (27)
16.2.4攻击IV：窃听 (27)
16.3 哈希敏捷计划 (28)
17. IAB考虑 (28)
18. IANA考虑 (28)
18.1 STUN方法注册 (28)
18.2 STUN属性注册 (29)
18.3STUN错误码注册 (29)
18.4STUN UDP和TCP端口号 (30)
19.从RFC3489的改变 (30)
20.贡献者 (31)
21.致谢 (31)
NAT的会话穿透用法 (STUN)
1.简介
本说明书中说定义的协议—会话穿透NA T用法，为处理NA T提供了一种工具。它提供了一种为端点决定由NA T分配的和端点本身私有地址和端口相关联的IP地址和端口的方法。他也提供一种保持NA T绑定的方法。本协议的扩展可用于两端点的连接检测[MMUSIC-ICE]，或者两端点之间的包中转[BEHA VE-TURN].
为保持工具的特性，本说明书定义了一种可扩展的包格式，几种传输层协议之上的操作以及两种鉴权形式。
STUN被试图用于解决一种或者多种NA T穿透。这些解决方案即是为我们所知的STUN 用法。每种用法描述了STUN怎样被用于实现NA T穿透解决方案。典型地，一种用法指明什么时候STUN消息被发送，哪种可选属性被包含，什么服务器被使用，以及什么鉴权方式被使用。交互式连接建立(ICE) [MMUSIC-ICE] 是STUN的一种使用方式. SIP Outbound[SIP-OUTBOUND]是另外的一种STUN用法。在某些情况下，一种用法需要扩展STUN，一种STUN扩展能以新的方法，属性，或者错误响应码的形式出现。更多的STUN 用法信息能够在第14节找到。
2.源于RFC3489的演变
STUN最初定义在RFC3489。RFC3489有时候被成为“经典的STUN”，它是以能完全解决NA T穿透问题的解决方案来描述的。在该解决方案中一个客户端能够发现它自己是否处在NA T的后面，判定NA T的类型，发现NA T外围的公网IP地址和端口，然后利用这个IP地址和端口填在协议体中，参见RFC3261。然而，自从RFC3489发布后，经验发现经典的STUN简直不能按一种分布式的解决方案来有效地工作。通过经典STUN获得的IP地址和端口有时候对端到端的通讯有用，但是有时候没有用。经典的STUN没有提供方法来是否应该发现，事实上，工作还是不工作，并且在它不能工作的情况下没有提供补救措施。更有甚者的是，经典STUN的判断NA T类型的分类算法被发现是不完美的，许多NA T不完全符合由它定义的类型。
经典STUN也存在一种安全弱点—攻击者能够在特定的拓扑和限制下提供错误的映射，这基本上不能通过加密方式来解决。尽管这个问题在本说明书中仍存在，但是通过使用STUN更完善的解决方案使得攻击被缓解了。
鉴于这些原因，本说明书淘汰了RFC3489，并且将STUN描述成一种工具用于完全穿透NA T解决方案的一部分。ICE [MMUSIC-ICE]是一种为像SIP那样基于offer/answer [RFC3264]策略的协议提供完全的解决方案。SIP Outbound [SIP-OUTBOUND]是一种sip信令完全穿透的解决方案，它以完全不同的方法使用STUN。因此，一个协议可能能够由它自己使用STUN作为一种解决方案，这类的用法没在这描述，由于上述原因它被强烈的阻止了。
这里描述的上了线的协议仅是轻微地改自经典STUN。运行在TCP和UDP之上的协议的扩展是一个更加结构化的方法。一个极其巧妙的让应用程序使用STUN的机制是偷用RFC3489中定义的128位事物ID中的32位，允许改变向后兼容。编码的地址映射使用一种新的异或格式。还有其他的，更小的改变，参见19节更加完整的描述。
由于使用范围的改变，STUN已经从"Simple Traversal of UDP through NA T"更名为"Session Traversal Utilities for NA T"。略缩词仍为大家熟知的STUN。
3.操作概览
本节仅是描述性的。
/-----\
// STUN \\
| Server |
\\ //
\-----/
+--------------+ Public
Internet
................| NAT 2 |.......................
+--------------+
+--------------+ Private NET 2 ................| NAT 1 |.......................
+--------------+
/-----\
// STUN \\
| Client |
\\ // Private NET 1
\-----/
Figure 1: One Possible STUN Configuration 一种可能的STUN配置如图1所示。在这种配置下，有两种实现STUN协议的实体（成为STUN代理）。图中底下的代理是客户端，它连接到私网1。这个私网通过NA T1连接到私网2.私网2通过NA T2连接到公网。图中最上面的代理是位于公网的服务器。
STUN是一个client-server协议。它支持两种类型的事物。一种是request/response事物，在这种事物中，客户发送一个请求到服务器，服务器返回一个响应。第二种是指示事物，在这种事物中，两种代理（client或者server）发送一个指示并不产生响应。两种事物都包含一个随机选择的96位的事物ID号。对请求/相应事物，这个ID号允许产生它的客户端将响应和请求相关联；对于指示事物，事物ID用于调试。
所有的STUN消息都以固定的头部开始，头部包含一个方法，一个类别，和一个事物
ID号。方法指明各种各样的请求或者指示。本说明书仅仅定义一种方法—Binding，其他的方法有望在其他的文档中定义。类别字段表明该消息是一个请求，一个成功的响应，一个错误响应，还是一个指示。紧跟固定头部的是0个或多个的TLV属性，为具体消息传递附加信息。
本文档定义一个唯一的称作Binding的方法。该方法能被用于请求/响应事物或者指示事物。当被用在请求/响应事物中的时候，方法可以用于决定一个NA T分配给client的特定的binding。当被用在请求/响应事物或者指示中的时候，方法可以用于保持这种binding有效。在binding请求/响应事物中，绑定请求由STUN客户端发送到STUN服务端。当绑定请求到达server的时候，他可能穿过STUN Client和STUN Client之间的一个或者多个NA T（在图1中有两个这样的NA T）。当绑定请求通过Nat的时候，Nat将修改数据包的源通讯地址（指源IP地址和源端口号）。因而，server收到的请求的源通讯地址将是由NA T创建的接近server那边的公网的IP和端口。这个地址成为反射通讯地址。STUN server 复制该源通讯地址到一个STUN绑定响应的XOR-MAPPED-ADDRESS属性中，并返回该绑定响应到客户端。当该响应数据包返回通过NA T的时候，NA T将修改IP头的目的地址，但是包含在STUN 响应数据包体XOR-MAPPED-ADDRESS属性中的通讯地址将不会被修改。这样，client能够学习到最外面NA T分配的关于STUN server的通讯地址。
在某些情况下，STUN必须服用其他的协议（如[MMUSIC-ICE], [SIP-OUTBOUND])。在这些情况下，必须有一种方法来监视一个包，判定它是一个STUN包还是不是。STUN在包头提供三种有固定值的字段来达到该目的。如果这样不够的话，STUN数据包还可以包含一个FINGERPRINT值，能够用于区分数据包。
STUN定义了一系列的一个用法能够决定使用的可选过程，称为机制。这些机制包括DNS发现，对于备选server的重定向技术，一个用于复用的指纹属性，以及两个鉴权和消息完整交换。鉴权机制解决一个用户名，密码，以及消息完整值的用途。两种鉴权机制，长期证书机制和短期证书机制被定义在本说明书中。每一种用途详述了该用途允许的机制。
在长期证书机制中，客户和服务器共享一个预先备置的用户名和密码并执行一个源自（但是细节不同）HTTP定义的领会挑战/响应交换。在短期证书机制中，client和server通过一些优先于STUN交换的带外方法交换用户名和密码。这些用于完整性保护和鉴权请求和响应。没有挑战或暂未使用。
4.术语
在本文档中，关键词”必须”,”不允许”,”要求”,”可以”,”不可以”,”应该”,”不应该”,”建议”,”可能”,”
可选” 是根据BCP14,RFC 2119[2]的规范描述STUN实现需要的不同层次。
5.定义
STUN Agent：一个STUN Agent是一个实现了STUN协议的实体。该实体既可以是STUN客
户端，也可以是STUN服务端。
STUN Client：一个STUN client是一个发送STUN请求和接受STUN响应的实体。一个STUN 客户端能够发送指示。在本说明书中，词条STUN client和client是同义词。
STUN Server：一个STUN client是一个发送STUN响应和接受STUN请求的实体。一个STUN 客户端能够发送指示。在本说明书中，词条STUN server和server是同义词。
Transport Address：IP地址和端口号的组合（如UDP和TCP端口号）。
Reflexive Transport Address：一个客户端学习到的能够标示该客户端的被server看得到的通讯地址。当一个客户端和另一个主机被一个NAT阻隔的时候，反射通讯地址描述NAT公网一边分给客户端的映射地址。反射通讯地址从STUN响应消息中的映射地址属性（MAPPED-ADDRESS or X OR-MAPPED-ADDRESS）学习到。
Mapped Address：和反射地址一个意思。这个词条保留仅仅是由于历史原因以及归功于属性名MAPPED-ADDRESS 和X OR-MAPPED-ADDRESS。
Long-Term Credential：一个描述客户端和服务端共享私密的用户名和密码。长期证书通常授给client当订阅者注册一个服务的时候并保持到订阅者离开改服务或者显式改变证书关系。
Long-term Password：长期证书的密码。
Short-term Credential：一个描述客户端和服务端共享私密的临时用户名和密码。短期证书通过一些server和client之间的协议机制俩获得，预处理STUN交换。一个短期的证书由一个显式的临时域，该域可能基于一段指定的时间（例如5分钟）或者一个事件（例如结束一个SIP对话）。短期证书的指定域由应用程序用途定义。
Long-Term Password：短期证书的密码。
Attribute：一个能附加到STUN消息的类型-长度-值对象的STUN词条。属性分为两类：comprehension-required和comprehension-optional。STUN代理可以安全地忽略它们不能理解的comprehension-optional属性，但是如果它包含一个不能理解的
comprehension-required属性，它将不能成功处理一个消息。
TRO：重传时间到，定义了一个发送请求和第一次重传请求的初始的时间周期。
6.STUN消息结构
STUN消息使用网络顺序的二进制编码（最重要的字节或者八位优先，通常称作
big-endian）。传输顺序在RFC791【RFC0791】的附录B中详细描述。注意，数据常量是十进制的（基数是10）。
所有的STUN消息必须以20字节的头部开始，紧跟0个或者多个属性。STUN头部包含一个STUN消息类型，巧妙的方法值，事物ID和消息长度。
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
每一个STUN消息最重要的2bits必须为0。当STUN和其他协议在同一端口上复用的时候，这能够区分STUN的数据包。
消息类型字段定义了消息类别（请求，成功响应，失败响应，或者重定向）和STUN
消息的消息方法（基本功能）。尽管有4种消息类型，但是在STUN中仅有两种事物：请求/响应事物（包含请求消息和响应消息）和指示事物（包含单一的指示消息）。响应类型分为错误和成功的响应来辅助快速处理STUN消息。消息类型域被分解在如下的结构中： 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
消息类型域中的比特位从最重要（M11）到最不重要（M0）来显示。M11到M0标示一个方法的12位编码。C1和C0标示类型的编码。0b00的类型是一个请求，0b01的类型是一个指示，010类型是一个成功的响应，0b11是一个错误的响应。本说明书定义了唯一的一个方法：Binding。方法和类别是正交的，因此，对于每个方法，一个请求，成功响应，错误响应和标示都可能是该方法的。扩展定义的新方法必须指明对于改方法哪种类型被允许。
例如，一个绑定请求拥有类别class=0b00（request）和method=0b000000000001 (Binding)并且编码到前16位的为0x0101。
注意：这种不幸的编码方式归功于【rfc3489】中值的安排，它没有考虑指示，成功和错误的比特域的使用。
巧妙域必须包含固定的网络序的值0x2112A442。在RFC3489中，这个域是事物ID 的一部分；把这个域放在这里允许一个主机检测客户端是否理解本修订说明书所附加的特定属性。另外，当STUN在相同端口上复用其他协议的时候它辅助区分STUN包和其他协议包。
事物ID是一个96bits的标识符，用于唯一标示一个STUN事物。对于请求/响应事物，该标识符被STUN client挑选给请求，并且有server在响应中传回。对于指示（indication），它由发送它的代理挑选。他主要为关联请求和响应服务，它也为特定的类别免受攻击而有一
定的作用。Server也使用事物ID来作为一个经过所有客户端的每个事物的唯一关键字。由此，事物ID必须统一地，随机地从0—2^96-1中选取，可以是一个加密的随机串。重传相同的请求使用相同的ID，但是client必须为一个先的事物挑选新的事物ID，除非新的请求是面向bit的与先前请求相同的并且从相同的通讯地址发送到相同的IP地址。Success和error响应必须携带和他们相关联的请求的事物ID。当一个代理在相同端口上即是server 有是client的时候，代理发送的事物ID和接受道德事物ID没有关系。
消息长度域必须包含不包括20字节头部的STUN消息的字节大小数。由于所有的STUN属性被填充成4字节的组合，因而此域的最后两bit总是0.这也提供了一种区分STUN 数据包和其他协议包的方法。
紧跟STUN固定头部的是0哥或者多个属性。每个属性都是以TLV编码的。编码细节和属性本身将在15节给出。
7.基本的协议处理
本节定义了STUN协议的基本处理。他描述了消息是怎么样形成的，怎样发送，当他们到达时怎样被处理。也详细定义了绑定方法的处理。本文档其他的节描述了在特定条件下选择使用可选的处理的一种方法。其他的文档可能会定义其他的STUN扩展，通过附加新的方法，新的属性或者新的错误响应码。
7.1形成一个请求消息或一个指示消息
当形成一个请求或一个指示消息，代理必须遵从第6节的规则构造头部。另外，消息类别必须是“Request”或者“Indication”（按实际情况而定），方法必须是绑定或者其他文档定义的方法。
代理添加方法或者用法指定的所有属性。例如，某些用法可能指定代理使用一个鉴权方法（section10）或者FINGERPRINT属性（section8）。
如果代理发送一个请求，它可以在请求中添加一个SOFTWARE属性。代理可能在指示消息中包含一个SOFTWARE属性，这有方法决定。STUN的扩展应该讨论SOFTWARE 在新的只是中是否有用。
对于没有鉴权的绑定方法，不需要任何属性除非用法指定了。
在知情的情况下，所有的通过UDP发送的STUN消息应该短语路径的MTU。如果不知道路径的MTU，消息应该小于Ipv4首跳的576字节【RFC1122】以及Ipv6首跳的1280字节【RFC2460】。这个值和IP包的总大小有关。因此，对于Ipv4，实际的STUN消息长度应该小于548字节（576-20字节的IP头部，减8字节的UDP头部，假设没有IP可选项被使用）。STUN无能力解决请求小于MTU但是响应大于MTU的情况。不要认为这种限制将是STUN的一个问题。MTU的限制是应该，不是必须的，来证实STUN本身被用于探测MTU的特征[BEHAVE-NAT]。
除此之外或者类似的应用，MTU限制必须被遵从。
7.2发送请求消息或者指示消息
代理将发送请求或者指示消息。本文档说明了怎样通过UDP，TCP或者TCP之上的TLS来发送STUN消息；其他的通讯协议将在以后被添加。STUN用法必须指明那个通讯协议被使用，代理怎样决定接收者的IP地址和端口。第9节描述了用法可能选择使用的基
于DNS的方法来决定server的IP地址和端口。STUN可能使用任播地址，但是仅用于UDP 和鉴权没有使用的用法。
任何时候，一个client可能发送多个外发请求到相同的server（即是，多个不通事物ID 的事物被处理）。不像其他新事物的几率限制（例如ICE连接检查或者当STUN运行在TCP 之上的时候），一个client应该经过RTO间隔为server处理新事物滨且应该限制他自己在去10个外发事物对同一个server。
7.2.1通过UDP发送
当在UDP之上运行STUN，STUN数据包可能被网络丢掉。可靠的STUN请求/响应事物通过客户事物本身来重传请求消息来完成。STUN只是不会被重传；因此，通过UDP的指示事物是不可靠的。
客户端应该间隔一个RTO重传一个请求消息，每次重传，重传间隔时间翻倍。R TO是round-trip（RTT）的一个估计值，它的计算于RFC2988[RFC2988]描述，除两个例外。首先，RTO的初始值应该是可配置的（而不是RFC2988中推荐的3s）并且应该大于500ms。这种例外的“应该”情况是当请他机制被用来获取拥塞门限（如ICE为固定流率定义的那些），或者STUN用于不知道网路功能的非Internet环境。在固定线路接入链路，500ms这个值是被推荐的[KARN87]。当应用于STUN，RTT估计值不应该根据导致重传请求的STUN事物来计算。
客户端结束事物后应该缓存R TO值，并且作为下个事物重传到相同server的初始值（基于相同IP地址的）。该值应该在10分钟后被考虑失效并被丢弃。
重传会继续直到一个响应被收到，或者知道一个完全的Rc请求被发送。Rc应该是可配置的并且应该有一个默认值7。在最后的请求之后，如果持续时间等于Rm时间的RTO超时而没有收到响应（只要这个终结请求成功，提供了足够的时间来等待一个响应），客户端应该考虑事物已经失败了。Rm应该是可配置的并且应该由一个默认值16。如果有一严重的ICMP错误，一个STUN事物会被考虑失败【RFC1122】。例如，假设RTO的值是500ms，请求会在0ms，500ms，1500ms，3500ms，，7500ms，和31500ms被发送。如果client在39500ms 后没有收到响应，客户端会考虑事物超时。
7.2.2通过TCP或者TCP上的TLS发送
对于TCP或者TCP上的TLS，客户端开启一个连接到server。
对于STUN的某些用法，STUN只能通过TCp协议来发送。在这种情况下，它能够在没有任何辅助的分帧和复用下被发送。在另外一些用法下，有其他的扩展，他可能和其他数据复用TCP连接。
在这种情况下，STUN必须运行在允许代理提取完整的STUN消息和完整的应用层消息的用法和扩展指定的某些分帧协议的顶层。STUN服务运行在众所周之的端口或者由第9节中单独为STUN描述的DNS过程所发现的端口，并不能和其他数据复用。因此，没有分帧协议被用于连接这些server。当附加的分帧被使用，用法会说明客户端怎样应用它以及哪个
端口来连接。例如，在ICE连接检测的情况下，这些信息通过服务器和客户端的带外协商来学习到。
当STUN被自己运行在TCP之上的TLS时，TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite必须以最小值实现。这中实现也可能支持任何其他的ciphersuite。当他接受到TLS 的认证消息后，可弧度啊你应该验证认证并且探测认证所标示的位置。如果认证是无效的或者被取消，或者如果他没有标示合适的组，客户端不允许发送STUN消息否则继续进行STUN事物。Client必须验证server的身份。为了达到这一点，它遵从RFC2818【RFC2818】中3.1节定义的身份验证过程。该过程假设客户端引用一个URI。为了此使用，client处理第8.1节中的域名和IP地址为被解析引用的URI主机的一部分。然而，一个client可能被配置一系列可证书的域名和IP地址；如果一个标示其中一个域名或者IP地址认证被收到，client认为server的身份被验证。
当STUN被运行于和其他基于TCP之上的TLS协议复用连接，代理的密码套件和TLS 处理过程操作将被其他协议定义。
可靠的通过TCP或者TCP之上TLS的STUN将有TCP自己处理，在STUN协议层没有重传。然而，对于请求/响应事物，如果client在它发送SYN建立连接后经过Ti秒没有接受到响应，它认为事物已经超时。Ti应该是可配置的并且应该有一个默认值39.5s。这个值被挑选用来为默认的初始化RTO等同TCP和UDP的超时值。
另外，如果client不能建立TCp连接，或者在响应被接受前连接被重置或者失败，任何正在进行的请求/响应事物都被认为失败。
Client可能通过一个TCP（或者TLS-over-TCP）连接发送多个事物，并且它可能发送其他请求在接受先前的请求响应之前。Client应该保持连接是打开的直到：
●没有进一步的STUN请求或者指示通过该连接发送，并且
●没有计划使用通过该连接发送的STUN请求学习到的任何资源（如一个映射地址
(MAPPED-ADDRESS or XOR-MAPPED-ADDRESS)或者一个中传地址[BEHA VE-TURN]），并且
●如果在该端口复用其他的应用层协议，使用完其他协议之后，并且
●如果使用从一个已经建立通讯的远程伙伴学习到的被某些TCPNA T穿越技术需要的端
口（e.g., [MMUSIC-ICE-TCP]）。
在server端，server应该保持连接打开，让client关闭，除非server决定连接已经超时（例如，由于client从网络断开）。当连接仍然打开在NA T阻拦的时候，Client学习到的绑定将仍然有效。只有client知道它需要绑定多长时间。如果接收到请求的响应没有发送出去，Server不应该关闭连接。不允许一个server为了发送一个响应向client另开一个连接。在过载的情况下，Server应该采用有关连接管理的最佳的做法。
7.3接受一个STUN消息
本节说明一个STUN消息的处理过程。这里的处理过程说明是针对本说明书定义的STUN消息；附加的向后兼容规则将在第12节定义。这些附加的过程是可选的，并且用法
能够选择使用他们。首先，一系列的处理操作被应用取于类别。这遵从具体类别处理，如后面的子节所描述。
当一个STUN代理接受到一个STUN消息，它首先检查该消息是否遵从第6节描述的的规则。它检查首两位是否是0，然后是magic cookie域是否是正确的值，然后消息长度是否是切合实际的，然后检查方法域的值是否是支持的方法。如果消息类别是“success response”或“Error Response”，代理将检查事物ID匹配的事物是否仍在处理过程中。如果FINGERPRINT扩展被使用，代理检查FINGERPRINT属性是否存在并且他的值时都正确。如果任何错误被检测到，消息将毫无声息地被丢弃。在STUN和其他协议复用的时候，一个错误可能表示消息不是STUN消息；在这种情况下，代理应该试图解析出消息是另外协议的。
STUN代理为用法指定的鉴权机制做任何需要的检查（参看第10节）。
一旦鉴权检查被处理，代理检查消息的未知的属性和熟知的但不期望的属性。未知的但可选理解的属性必须被代理忽略。熟知的但不期望的属性应该被代理忽略。未知而要求理解的属性产生的处理过程依赖消息类别，将在后面描述。
在这种情况下，更进一步的处理依赖于请求的消息类别。
7.3.1处理一个请求
如果请求包含一个或者多个要求理解的属性，server回复一个420的错误响应码（未知属性）。并且包含一个UNKNOWN-A TTRIBUTES属性在未知的要求理解的属性列表响应中。
当运行在UDP上的时候，server接受到的请求可能是一个事物的第一个请求或一个重传。Server必须响应重传满足如下条件的属性被保留：如果client接受到重传的响应并且响应是发送给起始的请求，client和server的全部状态等同于起始重传的响应被收到的情况，或者所有响应都收到（在这种情况下，client使用先收到的）。Server最早的满足此要求的方法是在过去的40s内记住所有通过UDP收到的事物ID和他们相关的响应。然而，这要求server保存状态，并且对不要求鉴权的请求不合适。另一种方法是重处理请求和冲计算响应。最新的技术必须仅使用于幂等的请求（当一个请求的相同请求能够被安全重复而不影响系统的全局状态的时候，该请求被认为是幂等的）并且对于相同的请求导致相同的响应。绑定方法被认为是等幂的。注意相当少的网络事件能产生反射通讯地址值的改变，STUN的扩展必须讨论server上的不存储事物状态的请求重传的实现。
7.3.1.1形成一个成功或错误的响应
当形成响应（成功或错误）的时候，server遵从第6节中的规则。响应的方法和请求相同，消息能是“success response”或“Error Response”。
对于错误的响应，server必须添加上述处理过程指定的包含错误码的ERROR-CODE属性。错误原因短语不是固定的，但是应该在某种程度上符合错误码。对于特定的错误，附加属性被添加到消息。这些属性有错误码指定的描述拼出。例如，对于错误码420（未知属性），
server必须包含一个UNKNOWN-A TTRIBUTES属性。特定的鉴权错误也导致属性被添加（参见第10节）。扩展可能定义其他的错误和/或者附加属性在错误的情况下被添加。
如果server使用一个鉴权机制鉴权，server应该添加合适的鉴权属性到响应中（参加第10节）。
Server也添加由具体方法或用法要求的任何属性。另外，server应该添加SOFTW ARE 属性到消息。
对于绑定方法，不要求额外的检查除非用法指定了。当形成成功的响应，server添加一个XOR-MAPPED-ADDRESS属性到响应，属性内容是请求消息的源地址。对于UDP，这是请求的源IP地址和源UDP端口。对于TCP和TLS-over-TCP,这是TCP连接的server可见的源IP地址和源TCP端口。
7.3.1.2发送成功或错误的响应
响应（成功或错误的）在接受请求的相同端口上发送。如果请求是在UDP上接受到的，目的地址和端口号就是接收到请求的源IP地址和端口号，并且源IP地址和端口号就是接受到请求的目的IP地址和端口号。如果请求是通过TCP或TLS-over-TCP接受的，响应从接受请求的相同连接发送。
7.3.2处理一个指示
如果指示包含未知的要求理解的属性，指示被丢弃或者被停止处理。
代理进行用法和方法要求的额外的任何检查。如果所有的检查成功，代理将处理改指示消息。对指示消息不产生响应。
对于绑定方法，没有要求额外的检查或处理，除非用法指定。代理接受消息仅仅在有NA T阻隔的时候刷新“binding”。
当指示消息不是通过UDP重传的时候，发送代理没有必要处理指示重传。
7.3.3处理一个成功响应
如果成功响应包含未知的要求理解的属性，响应被丢弃并且事物被认为失败。
Client做方法或用法指定的任何额外的检查。如果所有检查通过，client将处理成功响应。
对于绑定方法，client检查响应中的XOR-MAPPED-ADRESS属性。Client检查地址族指定的地址。如果他是一个不支持的地址族，属性将被忽略。如果是一个支持的但是不期望的地址族（例如，绑定事物通过Ipv4发送，而地址族指定的却Ipv6），client可能接受并使用该值。
7.3.4处理一个错误响应
如果错误响应包含未知的要求理解的属性，或者如果错误响应不包含一个ERROR-CODE属性，事物被简单地认为失败。
Client然后做鉴权机制指定的任何处理（参见第10节）。这将试图产生一个新的事物。
在这种情况下的处理过程依赖于错误码，方法和用法；一下是默认的规则：
●如果错误码是300到399，client应该考虑事物失败除非ALTERNA TE-SERVER扩展正
在被使用。参见第11节。
●如果错误码是400到499，client声明事物失败，在420的情况下（未知属性），响应应
该包含一个给出附加信息的UNKONW-A TTRIBUTES属性。
●如果错误码是从500到599的，client可能重发请求；client不必限制他们重发的时间。
任何其他的错误代码使client认为事物失败。
8.FINGERPRINT机制
这一节描述一个可选的STUN机制，当两种协议复用相同的通讯地址的时候，这种机制辅助区分STUN和其他协议的数据包。这种机制是可选的，并且如果当它被使用的时候STUN用法必须描述。FINGERPRINT机制不向后兼容RFC3489，并且在兼容被要求的环境下不能被使用。
在一些用法下，STUN消息和其他协议复用相同的通讯地址，例如实时传输协议（TRP）。为了应用第7节中的处理过程，STUN消息必须首先从应用层数据包分离。
第6节描述的STUN头部的三个固定域能够为这个目的使用。但是在某些情况下，这三个固定域可能不够用。
当FINGERPRINT扩展被使用，一个代理包含FINGERPRINT属性的消息被发送到其他代理。第15.5节将描述该属性的位置和值。当代理收到一个他认为是一个STUN消息的时候，然后，做一些基本检查之后，代理也检查包含FINGERPRINT属性的消息以及该属性是否包含正确的值。第7.3节描述了一个STUN消息全局处理时候的FINGERPRINT检查动作。额外的检查帮助代理检测其他协议的消息，这可能类似STUN消息。
9.server的DNS发现
这一节描述一个STUN的可选过程，允许client使用DNS决定服务器的IP地址和端口号。如果当扩展被使用的时候一个STUN用法必须描述。为使用这一过程，client必须知道一个server的域名和一个服务名；用法也必须描述client怎样获得他们。万一server的域名丢失或者合法的改变或者其他理由的改变，所以server的域名硬性编码到软件里是不推荐的。
当一个client希望定位一个公网中接受绑定请求/响应事物的STUN server的时候，SRV 服务名为“stun”。当他希望定位一个通过TLS会话接受绑定请求/响应事物的STUN server 的时候，SRV服务名为“stuns”。STUN用法可能定义额外的DNS SRV服务名。
域名由RFC2782指定的SRV过程被解析成通讯地址。DNS SRV 服务名作为输入该过程的服务名提供的。SRV查阅的协议是客户端将通过UDP（“udp”）和TCP（“tcp”）运行STUN的通讯协议。注意仅仅“tcp”在这时候由“stuns”定义。
RFC2782的过程允许确定待联系的server。RFC2782详细描述了SRV记录集的排序和使用细节。然而，RFC2782仅仅陈述了，client应该“试图连接(protocol, address, service)”却并没有给出如果失败了的细节。当按照这些过程，如果STUN事物没有接到响应而超时，client应该按照RFC2782中定义的顺序重新请求下一个server。当指示事物没有产生响应或超时，此类的重试仅仅对请求/响应传送有可能。
STUN请求的TCP，UDP端口都是3487。
STUN server的管理员应该在SRV记录中为TCP和UDP使用这一端口。在所有情况下，DNS中的端口必须反射server所监听的端口。STUN的TLS的默认端口是5349。如果server 软件支持决定初始消息是一个TLS还是一个STUN消息，server可以在TCP上运行STUN 端口上运行基于TLS的STUN。
如果没有SRV记录被发现，client执行一个域名的A或AAAA记录查询。结果将是一个IP地址列表，其中的每一个都能在默认的端口使用UDP或者TCP来联系，依赖于STUN 用法。对于需要TLS的用法，client使用默认的STUN TLS端口连接其中一个IP地址。
10.鉴权和消息完整性机制
本节为STUN描述client和server能用来提供鉴权和消息完整性的两个机制；这两个机制即是短期证书机制和长期证书机制。这两种机制是可选的，如果这些机制被使用的时候，用法必须指定。因此，client和server将知道基于哪种应用知识的机制被遵从。例如，一个公网上支持ICE的STUN服务器可能没有鉴权，因此在代理中支持连接检查的STUN server 功能可能使用短期证书机制。这两种机制的概览在第3节中给出。每一种机制说明了使用该机制的额外处理，扩展处理在第7节中说明。额外的处理发生三个不同的地方：当形成一个消息，当一个消息的基本检查执行后即收到一个消息，当详细处理错误消息的时候。
10.1短期证书机制
短期证书机制假设优先于STUN事物，，客户端和服务器使用一些其他协议以用户名和密码的形式交换证书。这种证书是有时间限制的。时间限制由用法定义。例如，在ICE用法[MMUSIC-ICE]，两个端点使用带外信令协商用户名和密码，该用户名和密码应用于媒体会话期间。
证书机制用于在每个请求和多个响应中形成一个消息完整性检查。在长期机制中没有任何挑战和响应；因此，重试被证书的虚拟时间限制特征所阻止。
10.1.1形成一个请求或者指示
对于一个请求或者指示消息，代理在消息中必须包含USERNAME和MESSAGE-INTEGRIT属性。MESSAGE-INTEGRITY属性的HMAC的计算在15.4节中描述。注意密码永远不会包含在请求或指示中。
10.1.2接受一个请求或指示
代理对消息进行基本的处理后，代理执行下面列出的有序的检查动作：
●如果消息不包含一个MESSAGE-INTEGRITY和USERNAME属性：
1.如果消息是一个请求，server必须用一个错误响应拒绝该请求。该响应必须使用一
个400的错误代码（Bad Request）
2.如果消息是一个指示，代理必须毫无声息地丢弃该指示。
●如果USERNAME不包含当前有效的服务器用户名值：
1.如果消息是一个请求，server必须用一个错误响应拒绝该请求。该响应必须使用一
个401的错误代码（Unauthorized）。
2.如果消息是一个指示，代理必须毫无声息地丢弃该指示。
●使用用户名关联的密码，如第15.4节中描述的那样为消息完整性计算值。如果结果值
与MESSAGE-INTEGRITY属性不匹配：
1.如果消息是一个请求，server必须用一个错误响应拒绝该请求。该响应必须使用一
个401的错误代码（Unauthorized）。
2.如果消息是一个指示，代理必须毫无声息地丢弃该指示。
如果这些检测通过了，代理继续处理请求或指示。Server产生的任何响应必须包含MESSAGE-INTEGRITY属性，使用密码计算其值用来鉴权该请求。响应不允许包含USERNAME属性。
如果任何检测失败，server不允许包含一个MESSAGE-INTEGRITY或者USERNAME 属性在响应消息中。这是因为，在这些失败的情况下，server不能决定计算MESSAGE-INTEGRITY需要的共享私密。
10.1.3接受一个响应
Client查找响应中的MESSAGE-INTEGRITY属性。如果存在，client通过15。4节中定义的方法计算响应的消息完整性值。如果结果值与MESSAGE-INTEGRITY属性的值匹配，响应被认为鉴权了。如果值不匹配，或者如果MESSAGE-INTEGRITY是空的，响应必须被丢弃，就好像它从没接受到一样。这意味着重传，如果可用，将继续。
10.2长期证书机制
长期证书机制依赖于长期证书，以用户名和密码的形式在client和server间共享。证书
被认为是长期的一旦它提供给用户，并且一直有效到用户不在是系统的订阅者，或者改变了。这是基本的传统的分给用户“登陆”的用户名和密码。
10.2.1形成一个请求
形成一个请求有两种情况。在第一种情况下，这是第一个从client到server的请求（由IP地址和端口号标示）。在第二种情况下，客户端在先前请求/响应成功完成后提交后续请求。想成请求所导致的401或438响应将在第10.2.3节中描述，它不被认为是“subsequent request”并且不使用10.2.1.2中描述的规则。
10.2.1.1第一个请求
如果client没有完成和server（如主机名标示的，如果第9节中描述的DNS过程被使用，或如果没使用就是IP地址）之间的成功的请求/响应事物，它应该忽略USERNAME, MESSAGE-INTEGRITY, REALM,和NONCE属性。换句换说，第一个请求将被发送就好像没有鉴权或消息完整性应用一样。
10.2.1.2后续请求
一旦请求/响应事物成功完成了，client将被server暂时置于某个域中，并且选一个鉴权用得用户名和密码。Client应该暂时缓存和server通讯的username, password, realm。当client 发送一个后续请求，他应该包含USERNAME, REALM, 和NONCE属性以及他们的临时缓存值。它应该包含一个由第15.4节描述的使用缓存密码计算的MESSAGE-INTEGRITY属性值。
10.2.2接受一个请求
Server处理完基本的请求检查之后，他按下面指定顺序的检查列表执行动作。
●如果消息不包含一个MESSAGE-INTEGRITY属性，server必须产生一个错误码为401
（为授权）的错误响应。这个响应必须包含一个REAM值。该值推荐使用STUN server 提供商的域名。响应必须包含server选择的NONCE。响应不应该包含USERNAME或MESSAGE-INTEGRITY属性。
●如果消息包含一个MESSAGE-INTEGRITY属性，但是没有忽略USERNAME,REAML
或NONCE属性，server必须产生一个错误码为400（Bad Request）的响应。响应不应该包含USERNAME,NONCE,REAML或MESSAGE-INTEGRITY属性。
●如果NONCE不在有效，server必须产生一个错误码为438（过期的Nonce）响应。该
相应必须包含NONCE和REAML属性并且不应该包含USERNAME或MESSAGE-INTEGRITY属性。Server可以验证临时性为了提供额外的安全。参见【RFC2671】4.3节的指南。
●如果USERNAME属性中的用户名不再有效，server必须产生一个错误码为401（未授
权）响应。该相应必须包REAML属性。该值推荐使用STUN server提供商的域名。该相应必须包含server选择的NONCE。响应不应该包含USERNAME或MESSAGE-INTEGRITY属性。
●使用USERNAME属性中关联的用户名的密码，按第154.节描述的计算消息完整性值。
如果结果值与MESSAGE-INTEGRITY属性中的值不匹配，server必须以错误响应拒接请求。该错误响应必须使用错误码401（未授权）。该相应必须包含NONCE和REAML 属性并且不应该包含USERNAME或MESSAGE-INTEGRITY属性。
如果这些检测通过，server继续处理请求。Server产生的任何响应（如上描述的情形），必须包含MESSAGE-INTEGRITY属性，使用用户名和密码计算其值以鉴权请求。REAML,NONCE,和USERNAME属性不应该被包含。
10.2.3接受一个请求
如果响应是一个401（未授权）的错误响应，client应该在心事物中重传请求。请求必须包含一个USERNAME，由client决定的作为错误响应中域的合适的用户名。请求必须包含复制自错误响应中的REAML。请求必须包含复制自错误响应中的NONCE。请求必须包含MESSAGE-INTEGRITY属性，该属性值使用USERNAME属性中的用户名关联的密码计算的。如果没有改变先前企图中的USERNAME或REAML或它关联的密码，Client不允许执行重试动作。
如果响应是一个响应码为438的错误响应（过期的Nonce），client必须使用438错误响应（过期的Nonce）中提供的新的NONCE来重试请求。这个重试不应该包含USERNAME,REAML和MESSAGE-INTEGRITY。
Client在响应中查找MESSAGE-INTEGRITY属性（无论成功或失败）。如果存在，client 按15.4节中描述的方法计算响应的消息完整性，使用他对请求使用的相同的密码。如果计算值和MESSAGE-INTEGRITY属性中的内容匹配，响应被认为是鉴权了的。如果不匹配，或者MESSAGE-INTEGRITY不存在，响应必须毫无声息地被丢弃。这意味着如果重传可用，将继续重传。
11.ALTERNATE-SERVER机制
本节描述STUN允许一个server重定向一个client到另一个server的机制。本扩展是可选的，当用法使用的时候必须定义。
一个server使用本扩展通过回复给请求一个错误码为300（试图转移）的错误响应消息来重定向开一个client到另外的server。Server必须包含一个ALTERNA TE-SERVER属性在错误响应中。错误响应消息可能被鉴权；但是，有ALTERNA TE-SERVER响应鉴权不可能或不实际的情况。
一个client使用本扩展俺如下处理一个300(试图转移)错误码。Client在相应中查找ALTERNA TE-SERVER属性。如果发现了，client认为本事物已经失败，并且按该属性中指定的server，使用先前请求相同的通讯协议重新发送请求。如果被鉴权了，该请求必须使用客户端发送请求中使用的而服务端进行重定向的那个相同的证书。如果server重定向到的是client在过去5分钟内已经试过的那个server，它必须忽略该重定向并且认为事物失败。这阻止了server的无限重定向循环。
12.向后兼容RFC3489
本节定义允许向后兼容RFC3489中定义的原始协议的程度的过程。本机制是可选的，这意味着仅适用于一个新的client能够连接旧的server，反之亦然。本过程使用的时候，用法必须定义它。
第19节列出了本说明书和RFC3489的所有改变。然而，并不是所有的改变都是重要的，因为“经典STUN”仅仅按很少的特殊的方式使用。为达到本扩展的目的，重要的改变如下。在RFC3489中：
●UDP是仅仅被支持的通讯协议
●Magic cookie域作为128位长的事物ID域的一部分。
●属性The XOR-MAPPED-ADDRESS不存在，绑定方法使用MAPPED-ADDRESS素火
替代。
●有三种comprehension-required属性，RESPONSE-ADDRESS, CHANGE-REQUEST, 和
CHANGED-ADDRESS在本说明书中被移除。
CHANGE-REQUEST 和CHANGED-ADDRESS现在是NA T行为发现用法[BEHA VE-NA T]的一部分，其他的不支持。
12.1client处理的改变
客户端想要和一个【RFC3489】的server交互操作，它应该发送一个使用UDP协议的使用绑定方法的不包含属性的请求消息到server。如果成功，从server收到的成功响应将包含一个MAPPED-ADDRESS属性而不是XOR-MAPPED-ADDRESS属性。一个client寻求和一个老的server交互操作，它也必须准备接受消息。此外，client必须忽略任何可能出现在响应中保留的comprehension-required属性。18.2节中保留的属性，0x0002, 0x0004, 0x0005, 和0x000B可能出现在遵从RFC3489server的绑定响应。除此改变之外的响应处理合上述描述的过程一样。
12.2server处理的改变
一个STUN server能够根据出现在magic cookie域折哦ingde正确值检测出给定请求是否是一个RFC3489client发送的。当server检测到一个RFC3489 client的时候，他应该copy 绑定请求中可见的magic cookie域值到绑定响应中该域，并且插入一个MAPPED-ADDRESS 属性替代一个XOR-MAPPED-ADDRESS属性。
在少数情况下，client可能包含一个RESPONSE-ADDRESS或者CHANGE-REQUEST 属性。在这些情况下，server将视这些为未知的要求理解的属性，并且回复一个错误响应。尽管使用这些属性的机制不再被支持，这种行为确实可接受的。
RFC3489版本的STUN没有考虑当和其他协议复用时高效地正确标示STUN消息的magic cookie属性和FINGERPRINT属性。因此，STUN实现了向后兼容RFC3489时不应该用于STUN和其他协议复用的情况。然而，这对于RFC3489中无效的复用也不会成为一个问题。
13.基本server行为
本节定义了基本的独立的STUN server的行为。一个基本的STUN server通过接受的和回复的STUN绑定请求提供给client几个反射通讯地址。
STUNserver必须支持绑定方法。它不应该使用长期或者短期的证书机制。这是因为鉴权请求的工作量大于简单处理它的工作量。同样的理由，它不应该使用ALTERNA TE-SERVER机制。它必须支持UDP和TCP。它可以支持STUN over TCP/TLS；然而，TLS在此基本的模式中提供极小的安全效益。它可以使用FINGERPRINT机制但不是必须的。由于单独的server仅仅运行STUN，所以FINGERPRINT没有提供利益。强求它可能破坏兼容RFC3489，但是这些兼容性在单独的server中是强烈要求的。单独的STUN server 应该像12节中描述的那样支持向后兼容RFC3489。
推荐STUN server的管理员为server提供第9节中描述的那样的DNS实体。
一个基本的STUN server本身不是NA T穿透的解决方案。然而，他可用于穿透NA T用法的一部分。这将在第14节中深入讨论。
14.STUN 用法
STUN本身不是NA T穿透的问题的一个解决方案。但是，STUN定义了一个工具可用于一个大的解决方案的内部。词条“STUN usage”用于任何使用STUN作为一个组件的解决方案。
目前为止，三种STUN用法被定义了：交互事连接建立（ICE）【MMUSIC-ICE】，SIP 的客户端初始化连接【SIP-OUTBOUND】和NA T行为发现【NEHA VE-NA T】。其他的用法将在以后定义。
一种STUN用法定义了怎样实际应用STUN—什么时候发送请求，怎么处理响应以及哪一种定义的可选的过程（或STUN的扩展）被使用。
一种用法也定义：
●哪种STUN方法被使用。
●什么鉴权和消息完整性机制被使用。
●如【RFC4107】中讨论的手动与自动的密匙获取的考虑。
●什么样的机制用来区分STUN消息和其他消息。当STUN运行在TCP上时，分帧
机制可能被要求。
●一个STUNclient怎么样确定STUN server的IP地址和端口。
●向后兼容RFC3489是否被要求。
●哪些这里定义的或其他扩展中的可选的属性（如FINGERPRINT和
ALTERNA TE-SERVER）被要求。
另外，任何STUN用法必须考虑该用法中的安全实现。大量的针对STUN的攻击被获悉（参见本说明书的安全考虑部分），以及考虑这些攻击怎样被阻止和减轻。
最后，一种用法必须考虑它的STUN用法是否是一个单方面为主的自我地址固定穿透NA T方法的一个例子，如果是的，解决RFC3424【RFC3424】中提出的问题。
15.STUN 属性
STUN头部之后的是0哥或多个属性。每个属性必须是16bits类型，16bits长度和值域的TLV编码。每一个STUN属性必须在32bits内结束。如上面所提到的，属性中所有域先传送最重要的位。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of STUN Attributes
长度域中的值必须包含该属性的优先填充的字节度量的长度值。由于STUN对齐属性在32位以内，不足4字节的被填充1，2或3字节的填充字段从而使其值包含一个4字节的组合。填充字段会被忽略，因而可以是任意值。
任何属性类型可能在STUN消息中出现不只一次。除非特别指定，否则出现的顺序是很重要的：仅仅首次出现的需要被接收者处理，任何的复制可能会被接收者忽略。
如果需要的话，为了允许本说明书未来的新版本添加新的属性，属性空间被分成两种。属性类型在0X0000和0X7FFF的是要求理解的属性，就而是说STUN代理不能成功处理消息除非它理解改属性。属性类型在0X8000和0XFFFF之间的是可选理解的属性，就是说如果STUN代理不理解这些属性，这些属性将被忽略。
STUN属性类型集由IANA管理。本说明书定义的初始类型集在18.2中能找到。
本节余下的部分描述本说明书定义的种各样的属性格式。
15.1MAPPED-ADDRESS
MAPPED-ADDRESS属性标示一个客户端的反射通讯地址。它包含8-bit地址协议族和16-bit端口，紧跟着标示IP地址的固定长度值。如果IP地址家族是Ipv4，地址字段必须是32位。