APP下载

DHCP Client按Option60分流的研究与实现

2011-09-25文荣李凯达王志谦

中国教育网络 2011年1期
关键词:标识符配置文件IP地址

文荣,李凯达,王志谦

(北京邮电大学网络技术研究院,北京,100876)

DHCP Client按Option60分流的研究与实现

文荣,李凯达,王志谦

(北京邮电大学网络技术研究院,北京,100876)

动态主机配置协议(DHCP)主要用来动态提供配置参数给因特网上的主机,一方面从DHCP服务器传送主机特定的协议配置参数到主机,另一方面自动分配网络地址给主机。目前本地局域网大多使用高速公共因特网接入技术和高速调制器, 并使用动态主机配置协议分配用户的主机地址。然而, 随着数字电视等业务的发展,用户家庭需要分配IP地址的设备越来越多,如何将用户不同设备的DHCP请求分流至特定的服务器就成为日益迫切需要解决的问题。本文针对目前在局域网普遍使用的DHCP及其为解决分流问题而引进的Option60机制进行简单的描述, 并具体阐述其实现方式。

动态主机配置协议;可选域60;中继代理;分流

Abstract:The Dynamic Host Configuration Protocol (DHCP) is mainly used to provide configuration parameters for hosts on the Internet. On the one hand, it transmit host-specific configuration parameters from the DHCP server to the client host, and on the other hand, it assign network addresses for the client host. Currently, most of the local area networks access Internet via high-speed public Internet access technologies and high-speed modulator. And use DHCP to distribute host address for the user's devices. However, with the development of digital television services, more and more devices need ip addresses to be assigned. How to user requests for different devices diverted to a particular DHCP server has become increasingly it’s a urgent problem to be solved that how to divert DHCP request from different user devices to specific server. This paper describes both the Option60 mechanism aiming at the DHCP commonly used in LAN and its diverting problems, and the implementation in detail.

Key words:Dynamic Host Configuration Protocol, Optional Field 60, Relay Agent, Diversion

1.问题的提出

在现今的网络中,IP地址的分配方式大多采取的是DHCP的方式。随着广电运营商为用户提供服务的增多(如接入Internet、IPTV、数字电视等),用户端的设备(如cablemodem、机顶盒等)也随之增多,对为这些设备提供IP地址的DHCP服务器而言,其压力越来越大,而且同时也不方便网络管理人员的管理。

因此,运营商们希望能实现如下场景:一个DHCP客户端从由某一厂商提供的一台特定的DHCP服务器上取得访问公网的IP地址,而观看数字电视又从另一厂商提供的DHCP服务器上获取设备的IP地址。也就是说,用特定的DHCP服务器为用户的设备(cablemodem、机顶盒等)分配IP地址这一需求日益突显出来。

本文针对上述问题进行研究并提出了一种实现方式。

2.DHCP过程概述

DHCP是通过DHCP服务器向提出申请的网络主机分配IP地址等网络配置参数。

如果要分配一个新的网络地址,DHCP服务器与客户间的协议交互如下:

客户在本地子网广播DHCPDISCOVER消息,若DHCP服务器与客户端不在一个子网,则由DHCP中继代理(relay agent)传递消息到服务器。

服务器端在收到DHCPDISCOVER后,以带有客户请求的网络地址yiaddr的DHCPOFFER响应,假如服务器发现DHCPDISCOVER来自relay agent,则将DHCPOFFER直接单播送至relay agent,由其单播送至客户,反之,则在本地子网广播。

客户从一个或多个服务器接收到一个或多个DHCPOFFER后选择其中一个获得配置参数,并将带有标识选中服务器的DHCPREQUEST在本地子网广播经由relay agent转发。若客户在规定时间内未收到DHCPOFFER,则重发DHCPDISCOVER。所有服务器将接收到DHCPREQUEST消息,根据DHCPREQUEST内的服务器标识,被选用的服务器根据客户的硬件地址chaddr和yiaddr唯一确认客户后,发送DHCPACK至客户端。若服务器不能满足客户在DHCPREQUEST内的配置请求,则响应DHCPNAK。若服务器在一定时间未从客户接收到DHCPREQUEST,则直接回复DHCPACK。

客户从服务器接收DHCPACK后,首先核对消息内的配置参数(如ARP,租用时间等) ,若不一致,则发DHCPDECLINE至服务器,如果一致则进行配置,之后客户与服务器间可以直接交互。当客户从服务器处接收DHCPNAK,则重新启动配置过程。一旦客户在规定时间内未收到服务器的响应,重传DCHPREQUEST消息,若10次重传后,仍未收到服务器的响应,则通知用户并回到配置初始化阶段重新开始。

当客户想释放由服务器提供的网络地址,可发送标识客户硬件地址chaddr 和网络地址ciaddr DHCPRELEASE。

DHCP 消息从客户经relay agent(可选) 至服务器,通常为广播包,但若客户已知服务器的网络地址,可直接发送单播包给服务器。relay agent将处理所有的广播包,首先检查消息内的网关地址giaddr,若不为零,说明在此relay agent之前,已有一代理对消息进行处理,giaddr不会被修改;若为零,relay agent将自己的网络地址填入消息内的giaddr 作为网关地址,同时将广播包转为单播包送至目的地DHCP 服务器。倘若消息本来就为单播包,则relay agent 不做任何处理。

一旦DHCP 服务器构造一个合适的DHCP响应包后,先检查giaddr域,假如此域的值不为零,服务器将响应包送至giaddr标识的relay agent的端口67。若giaddr 为零,而表示客户的网络地址ciaddr非零,说明客户已经有一个当前的网络地址,故可直接将响应包送至网络地址ciaddr。如若giaddr、ciaddr均为零并且广播标志位被设置为1,则服务器广播DHCP响应包DHCPOFFERPDHCPACK,若广播标志位未被设置,则服务器发送DHCPOFFERPDHCPACK至硬件地址为chaddr网络地址为yiaddr 的客户。对于DHCPNAK包,只要giaddr为零,服务器将其广播。

DHCP relay agent只接收单播的DHCP 响应包,其首先检查giaddr、yiaddr、chaddr、htype和hlen域,根据这些域值,relay agent能将DHCP消息送至客户。注意,relay agent不能修改消息包内的任何DHCP 域值,应该保持消息的完整性。

通常DHCP服务器和DHCP relay agent可利用硬件地址chaddr网络地址yiaddr将DHCP响应包送回至客户,但是有些客户在yiaddr未被正式配置时,不承认yiaddr 标识的网络地址,此时客户应该设置广播标志位为1 ,这样服务器和agent会广播此响应包而非发送DHCPOFFERPDHCPACK 至硬件地址为chaddr网络地址为yiaddr的客户,造成死锁。

3.Option60字段

目前本地局域网大多使用高速公共因特网接入技术和高速调制器,并使用动态主机配置协议分配用户的主机地址。然而,大量DHCP客户端设备的使用,也会引入标识如何标识客户端设备的问题。这个问题可以通过引进DHCP vendor class identifier 的信息域也就是所谓的Option60来解决。

通常,Option60是由客户端设备在形成DHCP报文时写入的,用以标识设备的属性。Option60包含n字节的信息,这些信息是由DHCP服务器解析的。设备供应商可以选择定义特定的一类标识符来传达特定的配置或其他有关识别客户身份信息。例如,标识符可能包含客户端设备的硬件配置信息。如果服务器不具备解析Option60字段的功能,那么服务器必须将其忽略。

4.解决方案及应用

4.1 解决方案

为解决本文所提出的问题,我们如图1设计系统逻辑结构:

标准一级relay的功能十分简单,负责将CPE发出的DHCP报文转发至二级relay,再将二级relay转发的DHCP服务器的报文发给CPE。

在标准的一级relay与DHCP服务器之间加上我们设计并实现的二级relay。二级relay用于检查DHCP报文中的Option60字段,根据Option60字段值的不同将报文转发至不同的DHCP服务器。简化的二级relay功能如下:

维护配置文件:二级relay会维护一个由我们定义规则,由用户来写入数据的配置文件。二级relay会根据配置文件的内容来转发一级relay的DHCP报文。配置文件的格式如下:

设备属性标识符@DHCP Server ip:DHCP Server ip:

‘@’符号之前的为设备属性标识符,用于标识某一类的设备。标识符支持正则表达式,所以设备标识符可以是一个具体的值串,也可是带有通配符的正则表达式。

图1 系统逻辑结构

‘@’标识符之后的是DHCP Server的IP地址,为某一类设备分配IP地址的服务器可能是一台也可能是多台。因此,‘@’之后可能是一个IP地址也可能是多个IP地址。

在配置文件的最后会加上一行默认属性的标识符,格式如下:

对于可能不带标识符或之前匹配都未成功的设备,就采用这行规则提供的DHCP服务器的IP地址对一级relay的报文进行转发。

上行中继:所有从标准一级relay转发来的广播或者单播DHCP消息都被此agent截取。然后对报文消息进行分析,取出报文的Option60字段的值,并参照配置文件的规则进行匹配。如果匹配成功,取出规则中DHCP 服务器的IP地址,再将报文转发至这些DHCP服务器。若不成功,则采用配置文件的默认规则对报文进行转发。从而达到了分流的目的,实现了特定的DHCP服务器对某一类网络接入设备分配IP地址的需求。

下行中继:接收从服务器过来的所有DHCP消息,并透传给标准一级relay。也就是说二级relay对DHCP服务器发来的消息不做任何处理就转发给标准一级relay。

以上详细论述了解决方案和系统逻辑结构,二级relay处理DHCP client端报文的代码流程如下:

4.2 实际应用

下面以广电网络接入网部分为例,在接入网处部署、应用我们的二级relay以实现分流的要求。网络拓扑图如图2。

从之前的论述中,我们知道在二级relay的配置文件里会有一系列规则。这些规则规定了某一类设备的DHCP服务器的IP地址。如图2所示,我们假定配置文件中规定了DHCP Server1是为PC、机顶盒分配IP地址的服务器,DHCP Server2是为cable modem分配IP地址的服务器,而DHCP Server3是为其他网络接入设备分配IP地址的。也就是说,对这些在配置文件中没有特定的规则与其相对应的设备,它们的DHCP请求都由二级relay转发至DHCP Server3。

在如图2的网络拓扑中,客户端从服务器得到网络配置的基本流程如下:

图2 实际应用网络

1. 客户端广播发送DHCPDISCOVER报文,CMTS在侦听到后转发给二级relay;

2. 二级relay提取出报文的Option60字段,并与配置文件中的规则进行匹配,如果是PC、机顶盒类的设备则将报文转发给DHCP Server1,如果是cablemodem则转发给DHCP Server2,如果是配置文件中没有规则对应的设备,则将它们的报文都转发给DHCP Server3;

3. 相应的DHCP服务器在收到DHCPDISCOVER报文后,会回复DHCPOFFER报文给二级relay,二级relay透传给CMTS,再由CMTS透传给客户端;

4. 收到DHCPOFFER报文后,客户端发出DHCPREQUEST报文,CMTS转发给二级relay,之后的处理等同步骤2;

5. 相应的服务器回复DHCPACK报文,对客户端的DHCPREQUEST报文予以确认,并透传至客户端;

6. 客户端收到DHCPACK后应再次检查配置参数( 如通过ARP探测分配的IP地址) ,如果合法则此次配置即告完成,否则回到步骤1再进行一次配置。

在实际应用后发现,按上述流程对客户端进行网络配置,能很好地缓解服务器的压力,并便于运营商管理为不同接入设备提供配置的DHCP服务器。

5.总结

现今,家庭用户需要IP地址的设备越来越多,而对这类设备多采用DHCP的方式配置网络参数。这也意味着DHCP客户端的报文流量在逐渐增加。本文提出并实现了一种加入解析Option60字段功能的中继代理。通过在实际应用中的检验,这种中继代理能很好地起到为客户端报文分流的功能。

[1] Droms R. Dynamic Host Configuration Protocol [M]. RFC 2131, 1997.3.

[2] Alexander S, Droms R.DHCP Options and BOOTP Vendor Extensions [M].RFC 2132, 1997.3.

[3] Patrick M.DHCP Relay Agent Information Option [M].RFC 3046, 2001.1.

[4] Wimer W. Clarifications and Extensions for the Bootstrap Protocol [M]. RFC 1542, 1993.10.

猜你喜欢

标识符配置文件IP地址
基于底层虚拟机的标识符混淆方法
从Windows 10中删除所有网络配置文件
用软件处理Windows沙盒配置文件
基于区块链的持久标识符系统①
铁路远动系统几种组网方式IP地址的申请和设置
互不干涉混用Chromium Edge
基于Zookeeper的配置管理中心设计与实现
公安网络中IP地址智能管理的研究与思考
《IP地址及其管理》教学设计
科研人员唯一标识符的理论研究现状剖析