TR-069的相关名词（其三-完）

其他TR-069相关名词

TR-069里的NAT穿透

这里首先要说一下，TR-069标准的交互场景，主要是基于ACS和CPE能够互相找得到对方的前提下进行的。通常会要求ACS和CPE双方都拥有公网IP，这样才能保证ACS下发的命令能够到达CPE端。

图1 - 通常情况下的TR-069拓扑

但有些地区的ISP往往会遇到公网IP不足只能使用CGNAT，亦或者是他们需要管理一连串多个CPE（比如Mesh组网）的情况，这种时候ISP便需要借助一些用于NAT穿透的协议来达到管理目的。STUN和XMPP便是里面的代表。

图2 - 有NAT设备的TR-069拓扑

STUN

STUN，全名是Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators，是在 RFC 3489 中公布的一组标准化方法，它允许应用程序发现它们与公共互联网之间的 NAT 设备或防火墙的存在，并且判断出NAT的类型。

后来，在 RFC 5389 中进行了更新，保留了许多原始规范作为方法子集，但删除了其他一些规范，其名字也被改成了Session Traversal Utilities for NAT。

RFC 3489 - STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

RFC 5389 - Session Traversal Utilities for NAT (STUN)

STUN交互采用classicstun和UDP报文，全程均采用明文，安全性相比XMPP来说比较低。

STUN通信时需要有STUN客户端和STUN服务器，STUN客户端内嵌在CPE的程序中，作为一个功能使用，而STUN服务器则部署在ACS的网络环境中，双方通过进行STUN Binding来保持链路畅通（也就是我们常说的"保活"）。

XMPP

XMPP，全名是Extensible Messaging and Presence Protocol（旧名叫做Jabber），是一种开放式的通信协议。它基于XML格式，支持两个或多个网络组件之间近乎实时地交换结构化数据。

它的定义内容主要包含于下方一系列文档：

• RFC 3920（已被 RFC 6120 取代）
• RFC 3921（已被 RFC 6121 取代）
• RFC 3922
• RFC 3923
• RFC 4622（已被 RFC 5122 取代）
• RFC 4854
• RFC 4979
• RFC 6122（已被 RFC 7622 取代）

其中最广泛使用的是下面的三个：

RFC 6120 - Extensible Messaging and Presence Protocol (XMPP): Core

RFC 6121 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence

RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format

和STUN相同，XMPP通信时也需要有XMPP客户端和XMPP服务器，XMPP客户端内嵌在CPE的程序中，作为一个功能使用，而XMPP服务器则部署在ACS的网络环境中，双方通过XMPP的正常通信来维持链路的畅通。

Option 43

DHCP Option 43，这是DHCP报文里的一个字段，在官方文档RFC2132中定义为用于传输Vendor特定信息的字段。

在ISP网络设备中，它常被用于给样机提供TR-069的配置信息。

也就是说，CPE在向DHCP Server获取IP地址时，DHCP Server会将ACS的信息也一并传递给CPE。

配合Option 43，Zerotouch的场景也就变得更加丰富了。终端用户家里的CPE无需提前进行ACS信息的配置，只需连上DHCP Server获取IP和Option 43后，CPE便可了解ACS的地址并向其发送交互信息。

图3 - Option 43示意图 

那么关于TR-069的基本介绍就到这里告一段落了，后面会开始介绍一些详细的TR-069报文交互，如果有兴趣的话，不妨点个小小的订阅，也欢迎大家积极发言，我们一同讨论更多的技术知识~