专利名称：一种实现认证的方法和系统的制作方法
技术领域：
本发明涉及网际协议(IP)网络技术，特别涉及一种在动态主机配置协 议(DHCP)中实现认证的方法和系统。
背景技术：
在全IP网络中，基于用户的接入认证是必不可少的，但是现有一些协议却 没有提供认证功能，比如DHCP。现有的DHCP主要用于在用户请求下为用户 分配IP地址。图1为现有DHCP工作流程示意图。如图1所示，包括以下步骤
步骤101: DHCP客户端向DHCP服务器发送DHCP发现(DISCOVER)报文。
当DHCP客户端首次登录网络时，向网络中的DHCP服务器广播一个 DHCP DISCOVER报文，以寻找DHCP服务器。
步骤102: DHCP服务器向DHCP客户端回送DHCP提供(OFFER)报文。
网络中的每一个有空闲地址的DHCP服务器均对DHCP客户端发出的 DHCP DISCOVER报文作出响应，向DHCP客户端回送DHCP OFFER报文， 并在DHCP OFFER报文的"你的地址(yiaddr)"域中携带所提供的网络IP地 址，以及与该IP地址相关的一些DHCP可选(options )配置参数信息。
步骤103: DHCP客户端向DHCP服务器发送DHCP请求(REQUEST)报文。
DHCP客户端从接收到的多台DHCP服务器回送的DHCP OFFER报文中 选择一个DHCP OFFER报文，比如选择最先到达的DHCP服务器，并广播一 个DHCP REQUEST报文，以告诉网络中的各DHCP服务器，DHCP客户端将 指定接受哪台DHCP服务器提供的IP地址。
步骤104:被DHCP客户端选中的DHCP服务器向DHCP客户端发送DHCP 确认(ACK)报文或DHCP未确认(NAK)报文。
如果IP地址配置成功，DHCP服务器向DHCP客户端回送一个DHCP ACK 报文，以确认IP租约的正式生效。DHCP ACK报文中同样携带有与IP地址相 关的一些配置参数，而且需要确保本步骤中的配置参数不能和步骤102中所提 到的配置参数发生冲突。
如果因为DHCP客户端所请求的IP地址已经被分配给其它DHCP客户端 等原因导致DHCP服务器不能满足DHCP客户端的请求，那么，DHCP服务器 将向DHCP客户端回送一个DHCP NAK报文，以通知DHCP客户端IP地址配 置失败。
后续过程中，DHCP客户端在接收到DHCP ACK报文后，还可以向网络发 送一个地址解析协议(ARP)数据包，以查询网络中有没有其它设备在使用该 IP地址，如果有，则向DHCP服务器发送一个DHCP拒绝(DECLINE )报文， 拒绝接受所配置的IP地址，并重新发送DHCP DISCOVER报文。
另夕卜，除被DHCP客户端选中的DHCP服务器以夕卜，其它的DHCP服务器 都将收回其曾提供的IP地址。
图1所示DHCP工作流程是以DHCP版本4 ( v4 )为例进行i兑明的，如果 是DHCPv6,除了净良文类型不同，即将图1中的DHCP DISCOVER, DHCP OFFER、 DHCP REQUEST以及DHCP ACK报文分别替换为请求(SOLICIT )、 通告(ADVERTISE )、 REQUEST和应答(REPLY)报文之外，其它工作流程， 如消息交互方式以及各寺艮文的功能等均与DHCPv4相同。
从上面的介绍可以看出，现有DHCP中并没有认证功能，所以，为提高安 全性，希望将现有认证机制引入到DHCP中。
现有技术中比较常用的认证机制为可扩展认证协议(EAP)。 EAP是一种 认证框架，能够支持多种不同的认证方式，而且EAP报文可以被不同的协议 K 载，比如认证、授权、计费(AAA )领域常用的两种协议，即远程用户拨号认 证系统(Radius )以及下一代AAA协议Diameter中均定义了承载EAP来进行
认证的行业标准。EAP主要包括四种报文格式，分别为请求(request)、响应 (response )、成功(success )以及失败(failure )。图2为现有EAP消息交互方 式示意图。如图2所示，EAP request和EAP response总是成对出现的，而且， EAP request和EAP response对的数量以及各自携带的信息是不固定的，需要根 据实际应用中所采用的认证方式而定。
现有技术中已经提出了一种将DHCP和EAP进行结合，从而实现用户认 证的方式，该方式通过添加新的DHCP报文才各式DHCPEAP来携带EAP载荷， 利用EAP的方法进行认证，并在认证成功后，为客户端分配IP地址及相关参 数。
图3为现有通过EAP实现DHCP中的用户认证的方法示意图。如图3所 示，包括以下步骤
步骤301: DHCP客户端向网络接入服务器(NAS )发送DHCP DISCOVER报文。
本步骤中的DHCP DISCOVER报文中携带有DHCP-AUTH-proto信息，用 来标识之后的步骤将使用EAP进行认证。
步骤302: NAS向DHCP客户端发送DHCPEAP报文，其中携带有EAP request消息。
步骤303: DHCP客户端向NAS发送DHCPEAP报文，其中携带有EAP response消息。
步骤304: NAS剥离DHCPEAP中的EAP载荷，并将该EAP载荷携带在 AAA协议，如Radius中发送至AAA服务器。
根据所使用的EAP认证方法的不同，本步骤中，可能需要DHCP客户端、 NAS以及AAA服务器之间进行多次信息交互。
步骤305: AAA服务器向NAS发送认证成功报文，比如Radius协议中的 访问接受(Access-Accept)报文。
步骤306: NAS向DHCP客户端发送DHCP OFFER报文。
的配置参数信息。
后续处理过程与图1所示的步骤103以及步骤104相同，不再赘述。
图3所示方法虽然通过EAP实现了 DHCP中的用户认证，但是该方法存 在着以下缺陷
首先，理论上在DHCP客户端发送出DHCP DISCOVER报文之后，会有多 个DHCP服务器进行应答。现有DHCP协议中是DHCP客户端从接收到的多个 OFFER中做出选择，但图3所示方法并未涉及这种情况该如何处理。设想如果 所有的DHCP服务器都是在认证完成后再发送OFFER, DHCP客户端再进行选 择，那么无疑会造成资源的浪费，因为认证是一项十分耗时的工作。但是如果 在认证之前进行选择，也就是说在DHCP客户端接收到第 一个DHCPEAP报文 时就做出选择，那么，这就与图1所示的DHCP客户端在接收到OFFER报文 后进行选择不一致，从而需要对现有报文格式进行较大的改动，增加了实现的 复杂度。
此外，如果认证失败，那么失败消息也需要由OFFER报文来携带，这样， OFFER报文中的"yiaddr"字段就失去了意义，DHCP客户端需要首先检查认 证成功还是失败，然后才能去检查OFFER报文，同样，造成的问题就是需要 对现有报文格式进行较大改动，增加实现的复杂度。
再有，图3所示方法没有考虑到重认证的情况，所谓重认证即是指在首次 iU正之后进^f亍的iU正。
发明内容
本发明实施例提供三种实现认证的方法，能够简单地在DHCP中实现认 证机制。
本发明实施例同时提供三种实现认证的系统，能够简单地在DHCP中实 现iU正机制。
本发明实施例的技术方案是这样实现的
一种实现iU正的方法，该方法包括
网络侧接收来自动态主机配置协议DHCP客户端的DHCP请求报文， 对所述DHCP客户端进行认证，并向所述DHCP客户端回送认证成功与否 的响应净艮文。
一种实现iU正的方法，该方法包括
网络侧对向自身发送报文的DHCP客户端进行认证，若认证成功，则向 所述DHCP客户端回送DHCP确认报文；若认证失败，则向所述DHCP客 户端回送DHCP未确认报文。
一种实现iU正的方法，该方法包括
网络侧接收来自DHCP客户端的DHCP发现报文，所述DHCP发现报
文中携带有快速确认选项信息；网络侧对所述DHCP客户端进行认证，并向
所述DHCP客户端回送认证成功与否的响应#艮文。
一种实现认证的系统，该系统包括DHCP客户端以及网络侧；
所述DHCP客户端，用于向所述网络侧发送DHCP请求报文，并接收
所述网络侧回送的认证成功与否的响应报文；
所述网络侧，用于在接收到来自所述DHCP客户端的DHCP请求报文
后，对所述DHCP客户端进行认证，并向所述DHCP客户端回送认证成功
与否的响应4良文。
一种实现认证的系统，该系统包括DHCP客户端以及网络侧；
所述DHCP客户端，用于向所述网络侧发送报文，并接收所述网络侧回
送的"i人证成功与否的响应报文；
所述网络侧，用于对所述DHCP客户端进行认证，若认证成功，则向所
述DHCP客户端回送DHCP确认4艮文；若认证失败，则向所述DHCP客户
端回送DHCP未确认报文。
一种实现认证的系统，该系统包括DHCP客户端以及网络侧；
所述DHCP客户端，用于向所述网络侧发送携带有快速确认选项信息的
DHCP发现净艮文，并接收所述网络侧回送的认证成功与否的响应报文； 所述网络侧，用于在接收到来自所述DHCP客户端的发现报文后，对所
述DHCP客户端进行认证，并向所述DHCP客户端回送认证成功与否的响 应报文。
可见，采用本发明实施例的技术方案，网络侧接收来自DHCP客户端的 DHCP请求报文或携带有快速确认选项信息的DHCP发现报文后，对DHCP客 户端进行认证，并向DHCP客户端回送认证成功与否的响应报文。由于是在接 收到DHCP请求报文或携带有快速确认选项信息的DHCP发现报文后，触发认 证流程，也就是说，在DHCP客户端已经获取到地址信息或DHCP客户端无需 按照选择方式获取地址信息的情况下触发认证流程，所以也就不存在由于采用 现有技术中的地址信息选择方式而造成的资源浪费以及需要对现有报文进行改 动等问题。再有，本发明实施例所述方案中，若认证成功，则网络侧向DHCP 客户端发送DHCP确认报文，若认证失败，则网络侧向DHCP客户端发送DHCP 未确认报文，即利用现有DHCP协议中的结果确认报文来回送认证结果信息， 无需像现有技术一样对原有报文格式进行更改，从而降低了方案实现的复杂度。
图1为现有DHCP工作流程示意图； 图2为现有EAP消息交互方式示意图3为现有通过EAP实现DHCP中的用户认证的方法示意图4为本发明方法第一个较佳实施例的流程图5为本发明方法第二个较佳实施例的流程图6为本发明方法第三个较佳实施例的流程图7为本发明方法第四个较佳实施例的流程图8为本发明系统第 一 个较佳实施例的组成结构示意图9为本发明系统第二个较佳实施例的组成结构示意具体实施例方式
为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实 施例，对本发明作进一步地详细说明。
在本发明的实施方式中，网络侧接收来自DHCP客户端的DHCP请求 报文，对DHCP客户端进行认证，并向DHCP客户端回送认证成功与否的 响应净艮文。
上述方案可以应用在对DHCP客户端进行认证的不同环境中 (1 )对DHCP客户端进行初次认证 在网络侧接收来自DHCP客户端的DHCP请求报文之前，还将进一步 包括DHCP客户端从网络侧获取地址信息，具体包括DHCP客户端向网 络侧发送DHCP发现报文；网络侧向DHCP客户端回送DHCP提供报文， DHCP提供报文中携带有提供给DHCP客户端的IP地址及配置参数信息。 (2 )对DHCP客户端进行重认证
在实际应用中，重认证可以由DHCP客户端触发，也可以由DHCP服务 器端触发。通常，DHCP客户端需要触发重认证的情况包括以下两种 A、 DHCP客户端重启，具体又分为两种情况
DHCP客户端记录了重启前的IP地址，DHCP客户端向DHCP服务器发 送DHCP REQUEST,并携带IP地址要求继续使用，同时请求相关配置参数；
或者，DHCP客户端没有记录重启前的IP地址，这种情况如同首次认证 一样，需要向DHCP服务器发送DHCP DISCOVER。 B、地址更新(renew):
当DHCP客户端进行地址更新时，出于安全考虑或是周期性认证的一个手 段，需要重新进行认证。
而DHCP服务器端需要触发重认证的情况主要包括
A、 DHCP服务器由于某些特定原因更改对已接入用户的策略，或者收回 原来的认证。
B、DHCP服务器出于安全考虑需要周期性地要求DHCP客户端重认证。 如果是DHCP客户端触发的重认证，那么DHCP客户端将会主动向网
络侧发送DHCP请求报文，网络侧在接收到DHCP请求报文后，对该DHCP
客户端进行认证。
如果是网络侧触发的重认证，那么，首先由网络侧向DHCP客户端发送 强制更新报文，DHCP客户端在接收到该强制更新报文后，向网络侧发送 DHCP请求报文；网络侧在接收到DHCP请求才艮文后，对该DHCP客户端进 行认证。
上述过程中，根据所采用的EAP认证方式的不同，网络侧对DHCP客 户端进行认证的具体实现流程也将不同。
认证完成后，网络侧向DHCP客户端回送认证成功与否的响应报文，比 如若认证成功，则向DHCP客户端发送DHCP确认报文；若认证失败， 则向DHCP客户端发送DHCP未确认报文。
下面通过较佳实施例对本发明作进一步地详细说明
图4为本发明方法第一个较佳实施例的流程图。假设本实施例中网络侧 采用的EAP认证方式为OTP认证方式，那么，如图4所示，包括以下步骤
步骤401: DHCP客户端向NAS发送DHCP DISCOVER报文。
本实施例中，为便于描述，将网络侧按照其实际组成具体划分为NAS 和AAA服务器两部分。相对于DHCP客户端来说，NAS为DHCP服务器， 而相对于AAA月l务器来说，NAS为AAA客户端。
步骤402: NAS向DHCP客户端发送DHCP OFFER报文。
DHCP OFFER报文中携带有提供给DHCP客户端的IP地址以及相关配 置参数信息。
由于网络侧可能有多个DHCP服务器，而每个DHCP服务器在接收到 DHCP客户端发来的DHCP DISCOVER后，都可能作出响应，即向DHCP 客户端回送DHCP OFFER报文，所以，本步骤中，DHCP客户端可能会同 时接收到多条DHCP OFFER报文。
步骤403: DHCP客户端向NAS发送DHCP REQUEST报文。 DHCP客户端向NAS发送DHCP REQUEST报文，以请求IP地址和相 关配置参数。
如果步骤402中DHCP客户端接收到多条DHCP OFFER报文，那么， 本步骤中，DHCP客户端需要首先对多条DHCP OFFER进行选择，选择其 中 一个DHCP OFFER提供的IP地址作为自身的IP地址。DHCP客户端如何
进行选择与现有技术相同，此处不再赘述。
步骤404: NAS向DHCP客户端发送DHCPEAP报文。
由于需要对DHCP客户端进行认证，所以NAS向DHCP客户端发送
DHCPEAP报文，并在其中携带EAP Request消息，以请求DHCP客户端的ID。
步骤405: DHCP客户端向NAS发送DHCPEAP报文。
DHCP客户端在EAP Response中携带自身的ID,并将EAP Response 携带在DHCPEAP中发送至NAS。
步骤404和405所述请求ID的过程为EAP认证协议中规定的流程。
步骤406: NAS剥离DHCPEAP中的EAP Response消息，并携带在现 有AAA协议中发送到AAA服务器。
比如，可以使用现有AAA协议Radius中的4妄入请求(Access-R叫uest) 来携带EAP Response消息。
步骤407: AAA服务器生成携带有OTP的挑战字信息的EAP R叫uest 消息，并携带在现有AAA协议中发送至NAS。
比如，可以使用现有Radius协议中的接入挑战(Access-Challenge)报 文来携带EAP Request消息。
步骤408: NAS剥离出EAP R叫uest消息，并携带在DHCPEAP报文中 发送至DHCP客户端。
步骤409: DHCP客户端根据接收到的挑战字信息产生应答，并携带在 EAP-Response消息中，通过DHCPEAP报文发送给NAS。步骤410: NAS剥离DHCPEAP中的EAP-Response消息，并携带在现 有AAA协议中发送至AAA服务器。
比如，可以使用现有AAA协议Radius中的Access-Request来携带EAP Response消息。
步骤411: AAA服务器根据接收到的挑战字应答信息进行认证，并向 NAS回送认证成功与否的响应纟艮文。
AAA服务器根据挑战字应答信息进行认证的方法为现有技术，此处不 再赘述。
才艮据i人i正结果，AAA服务器生成表示认证成功的EAP-Success消息或 表示认证失败的EAP-Failure消息，并携带在现有AAA协议，如接入接受 (Access-Accept)或接入拒绝(Access-Reject)报文中发送给NAS。
步骤412: NAS根据认证结果，向DHCP客户端发送表征认证成功的
当然，依据现有技术，NAS在获知认证成功后，还需要进一 步确认DHCP 客户端是否可以使用步骤403中所请求的IP地址，如果可以，则发送 DHCPACK，如果不可以，则发送DHCPNAK报文。
对于本领域技术人员，本发明实施例仅为实现本发明所述方案的较佳方 式，但并不用于限制本发明的技术方案。比如，对于上述实施例来说，并不 局限在只能通过DHCPEAP报文来携带EAP Request和EAP Response消息， 只要能达到同样的目的，采用其它的方式也是可以的。比如，可以新定义两 个独立的才艮文类型DHCPEAPREQUEST和DHCPEAPRESPONSE，通过这两 个报文来携带EAP Request和EAP Response消息。
需要说明的是，图4所示较佳实施例中，网络侧采用的EAP认证方式 为OTP认证方式，如果采用其它认证方式，图4所示的EAP消息交互方式 将有可能不同，比如，步骤404-405本身就是可选步骤，可以省略，如果 省略步骤404 ~ 405，步骤406中NAS将通过现有AAA协议携带EAP-Start 消息，并发送至AAA服务器；再有，步骤407-410可能需要重复多次，比
如在MD5等认证方式中，就可能需要多次重复步骤407 ~ 410所述过程。 图4所示实施例为DHCP客户端首次进4亍认证时的实现流程，下面通过
两个较佳实施例来说明DHCP客户端进行重认证时的实现流程。
图5为本发明方法第二个较佳实施例的流程图，该实施例中的重认证由
DHCP客户端触发。当DHCP客户端需要renew地址或者带地址请求分配参
数时，直接向NAS发送DHCP REQUEST报文。
本实施例与图4相比，区别^又在于，缺少了图4中的步-骤401和402，
即发现和提供IP地址的过程，步骤501 ~ 510与图4所示的步骤403 -412
相同，不再赘述。
图6为本发明方法第三个较佳实施例的流程图。该实施例中的重认证由 网络侧触发，即在步骤601中由网络侧向DHCP客户端发送强制更新 (FORCERENEW )报文；步骤602中DHCP客户端接收到FORCERENEW 报文后，向NAS发送DHCP REQUEST报文。后续步骤603 ~ 611与图4所 示的步骤404-412相同，不再赘述。
通常情况下，图5和图6所示实施例用于实现重认证，但是在某些特殊 情况下，比如，DHCP客户端在初始接入网络时没有或者并不需要进行认证， 只需执行图1所示的普通DHCP流程。当DHCP客户端因为DHCP客户端 重认证情况中所提到的原因需要进行认证，或DHCP服务器因为DHCP服 务器重认证情况中所提到的原因需要进行认证时，虽然这两种情况下的认证 属于首次认证，但是却按照图5或图6所示流程执行认证过程。
上述三个实施例虽然在具体实现上有所不同，但是有一个共同点，即都 是通过DHCP客户端向网络侧发送DHCP REQUEST来触发网络侧进行认 证。本发明实施例中同时提供了另外一种认证方式网络侧接收来自DHCP 客户端的DHCP发现报文，DHCP发现报文中携带有快速确认选项信息；网 络侧对DHCP客户端进行认证，并向DHCP客户端回送认证成功与否的响 应报文。其中，网络侧向DHCP客户端回送iU正成功与否的响应报文的方法 包括若认证成功，则向DHCP客户端发送DHCP确认报文；若认证失败，
则向DHCP客户端发送DHCP未确认报文。而且，DHCP确认报文中进一步 携带有网络侧提供给DHCP客户端的地址信息。具体实现如图7所示。
图7为本发明方法第四个较佳实施例的流程图。与图4所示实施例相比， 区别在于步骤701中DHCP客户端向NAS发送的DHCP DISCOVER中携 带有快速确认(rapid commit)选项信息；NAS在接收到DHCP DISCOVER 后即进行认证，不再需要执行图4所示的步骤401和402的信息交互过程； 而且，步骤710中NAS向DHCP客户端回送确认报文之前，需要确认是否 可以为DHCP客户端提供IP地址，如果可以，且认证成功，则向DHCP客 户端发送DHCP确认报文，并在DHCP确认报文中携带提供给DHCP客户 端的地址信息。其余步骤702-709与图4所示步骤404-411相同，不再赘 述。
上述各实施例均是在默认DHCP为DHCPv4的情况下进行说明的，如 果将DHCPv4替换为DHCPv6，上述各实施例将同样适用，区别只是报文类 型可能有所不同，比如在图6中网络侧触发重认证的实施例中，步骤601、 602和611将相应地变更为重配置(Reconfigure ) 、 Renew以及Reply。
基于上述方法，图8为本发明系统第一个较佳实施例的组成结构示意 图。如图8所示，该系统包括DHCP客户端801以及网络侧802:
DHCP客户端801 ，用于向网络侧802发送DHCP请求报文，并接收网 络侧802回送的iU正成功与否的响应l艮文；
网络侧802，用于在接收到来自DHCP客户端801的DHCP请求报文后， 对DHCP客户端801进行认证，并向DHCP客户端801回送i人证成功与否 的响应净艮文。
当利用图8所示系统对DHCP客户端801进行初次认证时，DHCP客户 端801将进一步用于，向网络侧802发送发现才艮文，并4矣收网络侧802回送 的地址信息；网络侧802进一步用于，接收DHCP客户端801的发现报文， 并向DHCP客户端801回送地址信息。
当利用图8所示系统对DHCP客户端801进行重认证时，网络侧802
还可进一步用于，向DHCP客户端801发送强制更新报文；相应地，DHCP 客户端801在接收到该强制更新报文后，向网络侧802发送DHCP请求报文。
网络侧802完成对DHCP客户端801的认证后，向DHCP客户端801 回送认证成功与否的响应才艮文，比如，若认证成功，则向DHCP客户端回送 DHCP确认报文；若认证失败，则向DHCP客户端回送DHCP未确认报文。
图9为本发明系统第二个较佳实施例的组成结构示意图。如图9所示， 该系统实施例的组成结构与图8所示实施例相同，但各组成部分的功能有所 不同。
DHCP客户端901，用于向网络侧902发送携带有快速确认选项信息的 DHCP发现报文，并接收网络侧卯2回送的认证成功与否的响应报文；
网络侧卯2,用于在4妄收到来自DHCP客户端901的发现报文后，对 DHCP客户端901进行认证，并向DHCP客户端901回送iU正成功与否的响 应报文。
图8和图9所示系统实施例的具体构成以及工作流程与其对应的方法实 施例相同，不再赘述。
可见，采用本发明实施例的技术方案，不仅解决了如何在DHCP中进行 认证和重认证的问题，而且要实现所述认证，基本无需对现有报文格式进行 改动，相比于现有技术，降低了实现的难度和复杂度。
综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的 保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改 进等，均应包含在本发明的保护范围之内。
权利要求
1、一种实现认证的方法，其特征在于，该方法包括网络侧接收来自动态主机配置协议DHCP客户端的DHCP请求报文，对所述DHCP客户端进行认证，并向所述DHCP客户端回送认证成功与否的响应报文。
2、 根据权利要求1所述的方法，其特征在于，所述网络侧接收来自DHCP 客户端的DHCP请求报文之前，进一步包括所述DHCP客户端从所述网 络侧获取地址信息。
3、 根据权利要求2所述的方法，其特征在于，所述DHCP客户端从所 述网络侧获取地址信息的步骤包括所述DHCP客户端向网络侧发送DHCP发现报文； 所述网络侧向所述DHCP客户端回送DHCP提供报文，所述DHCP提 供报文中携带有提供给所述DHCP客户端的IP地址及配置参数信息。
4、 根据权利要求3所述的方法，其特征在于，若所述网络侧向所述DHCP 客户端回送一条以上DHCP提供报文，则该方法进一步包括所述DHCP客户端从所述一条以上的DHCP提供报文携带的一个以上 IP地址中选择出 一个IP地址，作为所述DHCP请求报文中请求的地址。
5、 根据权利要求1所述的方法，其特征在于，所述网络侧接收来自DHCP 客户端的DHCP请求报文之前，进一步包括所述网络侧向所述DHCP客户端发送强制更新报文。
6、 根据权利要求1所述的方法，其特征在于，所述网络侧对DHCP客 户端进行认证的步骤包括所述网络侧使用可扩展认证协议EAP认证方式，对所述DHCP客户端 进行认证。
7、 根据权利要求1所述的方法，其特征在于，所述向DHCP客户端回 送认证成功与否的响应报文的步骤包括 若认证成功，则所述网络侧向所述DHCP客户端发送DHCP确认报文； 若认证失败，则所述网络侧向所述DHCP客户端发送DHCP未确认报文。
8、 根据权利要求7所述的方法，其特征在于，所述DHCP请求报文中 携带有所述DHCP客户端请求的地址；所述网络侧向所述DHCP客户端发送DHCP确i^净艮文之前，该方法进 一步包括所述网络侧确认所述DHCP客户端是否可以使用所请求的地址； 如果可以，且认证成功，则所述网络侧向所述DHCP客户端回送DHCP
9、 一种实现iU正的方法，其特4正在于，该方法包括网络侧对向自身发送报文的DHCP客户端进行认证，若认证成功，则向 所述DHCP客户端回送DHCP确认报文；若认证失败，则向所述DHCP客 户端回送DHCP未确认报文。
10、 根据权利要求9所述的方法，其特征在于，所述DHCP客户端向所 述网络侧发送的报文中携带有所述DHCP客户端请求的地址；所述网络侧向所述DHCP客户端回送DHCP确认报文之前，该方法进 一步包括所述网络侧确认所述DHCP客户端是否可以使用所请求的地址； 如果可以，且认证成功，则向所述DHCP客户端回送DHCP确认报文。
11、 一种实现认证的方法，其特征在于，该方法包括网络侧接收来自DHCP客户端的DHCP发现报文，所述DHCP发现报 文中携带有快速确认选项信息；网络侧对所述DHCP客户端进行认证，并向 所述DHCP客户端回送认证成功与否的响应报文。
12、 根据权利要求11所述的方法，其特征在于，所述向DHCP客户端 回送iU正成功与否的响应才艮文的步骤包括若认证成功，则所述网络侧向所述DHCP客户端发送DHCP确认报文； 若认证失败，则所述网络侧向所述DHCP客户端发送DHCP未确认报文。
13、 根据权利要求11所述的方法，其特征在于，该方法进一步包括 所述网络侧确认是否可以为所述客户端提供地址；如果可以，且认证成功，则向所述DHCP客户端发送DHCP确认报文， 并在所述DHCP确认报文中携带提供给所述DHCP客户端的地址信息。
14、 一种实现认证的系统，其特征在于，该系统包括DHCP客户端以 及网络側；所述DHCP客户端，用于向所述网络侧发送DHCP请求报文，并接收 所述网络侧回送的认证成功与否的响应报文；所述网络侧，用于在接收到来自所述DHCP客户端的DHCP请求报文 后，对所述DHCP客户端进行认证，并向所述DHCP客户端回送认证成功 与否的响应报文。
15、 根据权利要求14所述的系统，其特征在于，所述DHCP客户端进 一步用于向所述网络侧发送DHCP发现报文，并接收所述网络侧回送的地址 信息；所述网络侧进一步用于接收来自所述DHCP客户端的DHCP发现报文， 并向所述DHCP客户端回送地址信息。
16、 根据权利要求14所述的系统，其特征在于，所述网络侧进一步用 于向所述DHCP客户端发送强制更新报文；所述DHCP客户端在接收到所述强制更新报文后，向所述网络侧发送 DHCP请求报文。
17、 一种实现认证的系统，其特征在于，该系统包括DHCP客户端以 及网络侧；所述DHCP客户端，用于向所述网络侧发送报文，并接收所述网络侧回 送的iU正成功与否的响应纟艮文；所述网络侧，用于对所述DHCP客户端进行认证，若认证成功，则向所 述DHCP客户端回送DHCP确iU艮文；若认证失败，则向所述DHCP客户 端回送DHCP未确iU艮文。
18、 一种实现认证的系统，其特征在于，该系统包括DHCP客户端以 及网络侧；所述DHCP客户端，用于向所述网络侧发送携带有快速确认选项信息的 DHCP发现报文，并接收所述网络侧回送的认证成功与否的响应报文；所述网络侧，用于在接收到来自所述DHCP客户端的发现报文后，对所 述DHCP客户端进行认证，并向所述DHCP客户端回送认证成功与否的响 应报文。
全文摘要
本发明实施例公开了实现认证的方法，网络侧接收来自动态主机配置协议(DHCP)客户端的DHCP请求报文或携带有快速确认选项信息的DHCP发现报文，对DHCP客户端进行认证，并向DHCP客户端回送认证成功与否的响应报文，若认证成功，则网络侧向DHCP客户端回送DHCP确认报文，若认证失败，则网络侧向DHCP客户端回送DHCP未确认报文。本发明实施例同时公开了实现认证的系统，应用本发明实施例所述的方法和系统，只需对现有协议进行较小改动，即可在DHCP中实现认证机制。
文档编号H04L1/16GK101350809SQ20071013045
公开日2009年1月21日 申请日期2007年7月19日 优先权日2007年7月19日
发明者赵宇萍 申请人:华为技术有限公司