DHCP技术规范

系统教程610 更新时间：2026-04-05 17:21:45

2024年3月13日发(作者：)

电视上网

电视上网 DHCP接入

技术规范

V1.0

2009年3月

电视上网

概述

本文档定义了电视上网DHCP接入规范。

电视上网

2. DHCP协议流程

2.1. DHCP包交互流程

时序图如下：

流程描述：

(1)机顶盒开机即检测本机存储中是否有接入层户名及密码，如果没有，则提示

要求输入，如果有，则将接入层用户名及密码加密后封装进 DHCP Discover包

中的Option 60字段里。

(2) 机顶盒将DHCP的Discover包广播出去，申请地址；中间的网络设备将会捕

捉到 DHCP Discover报文，并向里添加相应的Option82信息。

(3) DHCP服务器收到请求后将报文中的Option 60信息进行解包并组成认证报

文，送给认证服务器。

(4) 认证服务器将认证报文解密后进行认证。如果认证失败，传送结果给DHCP

服务器， DHCP服务器不对此用户做回应。如果认证成功，传送结果给DHCP服

务器，DHCP服务器将分配给用户的IP地址封装进 DHCP OFFER包中，再发送给

电视上网

机顶盒。

(5) DHCP服务器需要在回给客户端的DHCP OFFER包中插入认证信息（option125）

以便客户端能够对此信息进行鉴权，以辨别该OFFER包是否来自电信认可的

DHCP服务器。

(6) 机顶盒收到OFFER包后再次将应用层用户名增加前后缀与密码一同加密后

封装进 DHCP Request包（加密时随机数R、时间戳TS要重新生成），确认使用

OFFER包中分配的地址。此时DHCP服务器并不把 Option 60中的信息转给认证

服务器。

(7) DHCP服务器最后回复给机顶盒 DHCPACK包并加入option125信息，完成此

次地址申请。

续约时序

(1)机顶盒将在T1(租期的50%)时间发起第一次续约请求（Request报文），报文

发送方式为单播。

(2)机顶盒如果在第一次续约时没有得到回应的ACK报文后，将在T2(租期的

87.5%)第二次发送续约请求（Request报文），报文发送方式为广播。

(3)如果第二次续约仍然没有回应。将在租约到期后清除地址，重新发送

Discover包。注：机顶盒在续约的时候也必须带有Option60信息。

电视上网

2.2. Discover包内容要求-广播

补充说明：

.该报文中禁止包含租期、终端地址、等非本文规定的任何的可选 Option信息

2.3. Offer包内容要求 -单播

电视上网

2.4. Request包内容要求-广播

电视上网

2.5. ACK包内容要求-单播

电视上网

2.6. NAK包内容要求-广播

2.7. Release包内容要求-单播

2.8. Declient包内容要求

暂不做要求。

电视上网

2.9. 同时支持

DHCP和 PPPOE协议

要求机顶盒同时支持 DHCP和PPPOE协议：

(1) 开机后先发送DHCP请求，如果获得回应，即获取地址，接通IPTV业务；

(2) 一次DHCP的请求，按照协议栈的实现在第1秒，第9秒分别发起两次地址

请求；

(3) 如果DHCP请求在以上第1秒，第9秒共两次重发 Discover动作全部完成

后的3秒内仍然没有得到任何回应，则开始发送PPPoE请求，PPPOE请求发送3

次，每次间隔10秒；

(4) 在机顶盒发起PPPoE请求后，如果收到任何DHCP服务器的回应，均无条件

丢弃；

(5) 如果两次DHCP请求，三次PPPoE请求都没有回应，则提示用户网络连接故

障。

3. OPTION 60详细要求（ Authentication for DHCP Messages）

3.1功能描述

OPTION 60功能用来完成基于标准 DHCP协议，以在客户端输入用户名和密

码的方式进行的地址鉴权。

电视上网

目前在机顶盒中，使用接入帐号和业务帐号分开输入的方式；在 OPTION60

里将直接使用用户输入的接入层帐号和密码。接入层用户名与密码一旦输入之

后，应储存在硬件之中。当 PPPOE与 DHCP接入模式相切换时如果之前已经输入

过接入层用户名与密码，则可以无需再次输入，直接过渡至新的接入方式。

3.2实现流程

(1)在机顶盒启动后，如果 FLASH中没有储存用户名和密码信息，则马上弹出要

求输入用户名与密码的窗口由用户输入用户名和密码并保存用户名和密码，用户

名密码保存到机顶盒的 FLASH中，点击确定之后机顶盒重新启动，机顶盒再次

开机时发送的 DISCOVER报文中将在 OPTION60字段 authentication

information field插入 Message（其中 Message为用户名和密码的加密字符串，

加密算法见 1.3节）。

(2) DHCP平台（包括 DHCP服务器和认证服务器）收到

DISCOVER报文之后解析出 OPTION60字段中的用户名和密码，并在本地所保存的

用户名信息库中查找以进行真伪验证。

(3) DHCP平台验证用户名、密码，通过则向用户返回 OFFER报文；没有通过则

丢弃该报文不做任何处理。

(4) DHCP认证的详细流程详见 2.1节。

3.3加密算法

3.3.1 协议

描述机顶盒（STB）上保存：用户名（ UserID），密码（ Password）

(1) 在每次发出认证包前，STB生成随机数 R，R长度为 64bit ，8字节。

(2) STB生成时间戳 TS，TS定义为距离格林威志时间 1970年 0点秒数的 64bit

整型，强制转换 8字节长整型，实在位数不够的话高位补 0。

(3) 生成 DHCP认证的用户名 Login， Login为接入层帐号（ UserID）如

ad50980087@iptv。

电视上网

(4) STB生成密文 C = EnCry(R+TS+64Bit, Login)，C的长度为 8的整数倍长

度，根据Login的长度计算最终长度，例如如果Login 为120bit,那么C的长

度为128bit,依次类推，EnCry为 3DES对称加密算法，密钥为 R+TS后用 64位

0补足 192bit。

(5) STB生成密钥 Key = Hash(R+Password+TS)，其中 Key为 128bit，Hash()

为哈希算法，这里定义为 MD5；R+Password+TS就是 Byte的直接拼接。

(6) STB生成发送消息

Message = O+R+TS+Key+C，其中 O描述使用的对称加密算法

8bit，O=1：表示为上述描述的加密算法， O=其他数字：保留。

注释：1、加密时对认证用户名不足的位数采用 PKCS7 填充。

PKCS #7 填充字符串由一个字节序列组成，每个字节填充该字节序列的长度。

下面的示例演示这些模式的工作原理。

假定数据每块长度为 8字节，需要处理的数据长度为 9字节，则需要填充的字

节数等于 7，我们就在填充位补上 7个字节的 07。

数据： FF FF FF FF FF FF FF FF FF

PKCS7 填充后： FF FF FF FF FF FF FF FF FF 07 07 07 07 07 07 07。

2、密文中的整数字节排序采用 Big-Endian：

Big-Endian 和 Little-Endian 字节排序

字节排序含义 Big-Endian 一个 Word中的高位的

Byte放在内存中这个 Word区域的低地址处。Little-Endian 一个

Word中的低位的 Byte放在内存中这个 Word区域的低地址处。一个例子：

如果我们将 0x1234abcd写入到以 0x0000开始的内存中，则结果为

big-endian little-endian

0x0000 0x12 0xcd

0x0001 0x34 0xab

0x0002 0xab 0x34

0x0003 0xcd 0x12

电视上网

3.3.2 服务器上的处理

(1)根据Option 60中的 R、TS、密文 C，生成

UserID＝DeCry(R+TS+64Bit,C)。

(2)根据解密出的 UserID查找 Password，结合 Option60中的 R和 TS生成

Key=Hash(R+Password+TS)，比对 Option60中的 Key。

(3)在确认 UserID和 Key的正确性后，通过。

3.4 内置加密方式特别说明

(1) 单个机顶盒只需要内置一套加密方式，如果加密方式更新可以远程自动升级

新的加密算法。

(2) 在网络层认证完成后还需进行应用层认证。应用层认证发送帐号密码时仍然

要按照以上加密规则对信息进行加密。

3.5 OPTION 60字段说明

Option60字段鉴权规划参照《中国电信“我的e家”技术规范—— e家终端（e8）》

文中标准设计。

扩充Filed Type 31 -60 为 IPTV 机顶盒专用，其中Field Type 31定义为IPTV

机顶盒 DHCP认证的鉴权信息（具体为：接入层用户名、密码等信息加密后的密

文，加密算法见1.3

节）。

电视上网

125 详细要求（Vendor-Identifying Vendor Options）

OPTION 125 功能是对标准 DHCP协议一个补充标准，该功能的标准定义在

RFC 3925中。

DHCP服务器在完成验证将客户端的IP地址等信息封装成 DHCP OFFER包的

时候，将 OPTION 125信息封装进DHCP OFFER包中再发送给客户端。

DHCP 服务器在收到 Request包后，同样也会在回给机顶盒的 ACK包中添加

OPTION125的信息。

客户端收到 OFFER/ACK包以后，首先查看该 OFFER/ACK包中

OPTION 125中的约定的信息，并与预先存储的信息进行比对。比对结果为相同

则使用此 OFFER/ACK，如果比对信息不同则将此 OFFER/ACK丢弃。

OPTION 125 信息定义：该文中未提及的信息请参照 RFC 3925

Option-code=125

Option-len=DHCP 服务器厂商自定义

Enterprise-number1=DHCP 服务器厂商自定义

data-len1＝16

vendor-class-data1=SCCTCIPTVDHCPAAA

电视上网

参考资料

本文未包含的标准处理参考文档

在本文没有包含的DHCP相关配置和信息，请参照如下

RFC：

RFC 951 Bootstrap Protocol

RFC 1084 BOOTP vendor information extensions

RFC 1123 Requirements for Internet Hosts -Application and Sup

RFC 1534 Interoperation Between DHCP and BOOTP

RFC 1497 BOOTP Vendor Information Extensions

RFC 1541 Dynamic Host Configuration Protocol

Rfc 1533 DHCP Options and BOOTP Vendor Extensions

Rfc 2131 Dynamic Host Configuration Protocol

Rfc 3203 DHCP reconfigure extension

Rfc 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Rfc 3315 Vendor-Identifying Vendor Options for Dynamic Host Configuration

Protocol version 4

(DHCPv4)

Rfc 4477 Dynamic Host Configuration Protocol

Rfc 4702 The Dynamic Host Configuration Protocol (DHCP) Client Fully

Qualified

Domain Name (FQDN) Option

Rfc 4833 Timezone Options for DHCP

以上RFC如包含已废止内容，请参照新的RFC相关文档

本文发布于:2024-03-13，感谢您对本站的认可！

本文链接:https://www.fzithome.com/xitong/1710339995a324815.html

DHCP技术规范

发布评论取消回复

最近发表

相关推荐

标签列表

DHCP技术规范

发布评论 取消回复

最近发表

相关推荐

标签列表

发布评论取消回复