由于IP V4地址资源限制及IP V6设备的更新投入支持受限,目前大部分联网设备没有独立的IP地址(公网唯一地址),而是通过网络边缘服务器或家庭路由器的DHCP (Dynamic Host Configuration Protocol 动态主机配置协议)及NAT(Network Address Translation网络地址转换)功能实现TCP/IP数据传输。那DHCP是如何实现动态地址分配及智能物联终端如何通信的呢?
DHCP简介:
为什么会有DHCP?
–所有基于TCP/IP协议族实现的网络,其通信的一个重要基础就是IP地址,但对于大多数非专业的用户而言,IP地址是什么都不甚了解,要正确设置或者修改就更难了;
–但用户主机需要访问网络时,其网卡的IP却又是必不可少的–DHCP-Dynamic Host Control Protocol动态主机配置协议,就是用于简化主机IP地址设置的协议。通过DHCP,用户可以实现各项必要网络参数IP、DNS、Wins等的“零设置”,做到“即插即用。
DHCP的设计目标:
DHCP设计的主要目标是使TCP/IP网络的管理易于实现和维护:
自动IP地址的分配和配置,用户无需手工配置所有IP地址资源都由服务器统一存放、控制,集中IP子网的管理;对不使用的IP地址资源回收,提高利用率;
DHCP的优缺点:
可避免手工设置所产生的错误;
可避免多个用户使用相同IP地址而产生的冲突;
无需网络管理员干涉,减少网络管理工作量;
每个用户的IP地址是不固定的、随机性的,不利于管理和监控;
服务器故障可能会导致全网瘫痪,需要在网内做相应的冗余备份,网络组建成本增加。
DHCP要解决的问题:
DHCP目的是为了方便使用者,无需手工配置IP等相关信息,而DHCP又是一种基于IP运行的协议,在没有IP地址的情况下,DHCP又如何交互呢?
DHCP原理:
–DHCP分配的IP地址资源则具有时效性、是动态的,有利于提高IP资源的利用率;
– DHCP使用UDP协议报头,服务器端口67,客户端端口68;
– DHCP使用Request和Reply消息格式,DHCP的功能是依赖于报文的OPTION字段来进行实现的;
DHCP报文介绍:
DHCP报文直接借用了BOOTP的报文格式,其中的核心内容是OPTION;
DHCP OPTION格式:
每个Option都由Tag、Len、Data三大部分组成:
1、Tag表示本Option的作用;
2、Len表明后续Data的长度(Tag=0、255的option比较特殊,没有对应Data,当然也不需要Len长度);
3、Data内容作为Tag的补充详细说明。
– DHCP常见OPTION
RequestedIP Address,DHCP客户端曾请求并使用过的IP地址,通常出现在请求报文中。
Tag=50,Len=4 Data=ip.addr
IPAddress Lease Time,用户请求分配IP地址的使用时间(租约期),在DHCP客户端的请求报文和服务器的回应报文中都有,但以服务器分配为准
Tag=51,Len=4,Data=time;
DHCPMessage Type,DHCP协议交互的控制报文类型
Tag=53,Len=1,Data=1~7(只用了3bit);
ParameterRequest List,请求参数列表,标示客户端需要服务器分配的内容
Tag=55,Len=n(n≥1),Data=parameters 其中,具体的参数内容使用代码来标示,如:1为子网掩码、6为DNS-Server等等,有兴趣的可以查找rfc获得更详细的内容。
Clientidentifier,客户端身份识别,用以表示DHCP客户端的唯一身份,服务器据此查询数据库,唯一指定一个IP地址资源Tag=61,Len=n(n≥2);Data=hw.addr;
类似的Option还有OP=12,客户端的Hostname,服务器也可以据此唯一绑定一个IP地址。
End,Tag=255时,是一个特殊的Option,表示所有的Options字段已经填充完毕,后面没有了。
•DHCP的协议流程–
下面以DHCP客户端的角度来描述DHCP整个协议流程转换机制:
–INIT
客户机第一次启动之后,进入Init初始化状态,此时通过发送DHCP Discover,用于探测和发现服务器,同时状态切换到Selecting状态,该报文承载于UDP:67中,通过IP广播发送;
–Discover报文常见参数构成:
OP=1,BOOT RequestXid=Random,由Client确定
Ciaddr=0.0.0.0
Yiaddr=Siaddr=Giaddr=0.0.0.0
Chaddr=Client MAC Addr(客户端MAC地址)
–Discover报文常见Option构成:
RequestedIP addr=MAY
IP Addr Lease Time=MAY
ClientIentifier=MAY
ServerIdentifier=Must NOT
ParameterRequest List=MAY
–INIT
由于该请求为广播形式,通常在发送时会设置一个随机的实验延迟(≤10秒),以避免各个DHCP Client同时发送广播报文,对局域网造成不必要的影响;
–SELECTING
服务器收到Discover报文后,查看自己的IP Pool,如果IP Pool有地址可用,则选取一个地址,分配到Yiaddr中;如果没有可用IP,则丢弃;该报文被封装到UDP:68中,通过IP广播给Clients;
–SELECTING
DHCP Serv判断Discover报文接收端口的IP网段,然后从与之相同的DHCP IP Pool中按顺序选取一个服务器同时还必须分配Lease Time给用户:
如果Discover请求的Lease Time未指定,且Client还没有IP地址,则按照Server的默认设置分配;
如果请求的LeaseTime未指定,但Client已经获取了地址,则把该IP Binding的Lease time值返回;
如果Discover指定了Lease Time值,则无论Client是否已经有IP地址,Server可以选择在请求值和自己的默认Lease Time中选取一个进行分配;
–Offer报文常见参数构成:
OP=2,BOOT ReplyXid,由Client的Discover报文确定;
Ciaddr=0.0.0.0Yiaddr=Offered IP Addr,由Server确定;
Siaddr=BOOTP/DHCPServ IP AddrGiaddr,由Discover报文确定;
Chaddr=Client MAC Addr,from Discover;
–Offer报文常见Opton构成:
RequestedIP addr=Must Not
IP Addr Lease Time=Must
ClientIentifier=Must Not
ServerIdentifier=Must
ParameterRequest List=Must Not
–REQUESTING
在一个广播域中,客户端可能同时收到多个DHCP Serv的Offer,如何选择呢?
Client设置一个较短的收集时间段,在此期间可能收到的多个Offers,一般最先到达的Offer为优先,或者可以选择上次确定使用的Server,Client可以根据需要来进行选择,并向该Serv发起后续请求报文,同时状态切换为Requesting;
Client选定一个最优的Offer以后,就会根据该Offer提供的OPTION来发起Request,正式请求这些资源;以上内容被封装到UDP:68à67报文,通过IP广播发送到指定的Serv.
–Request报文常见参数构成:
OP=1,BOOT Request
Xid,根据Server的Offer报文确定
Ciaddr=0.0.0.0
Yiaddr=Siaddr=Giaddr=0.0.0.0
Chaddr=Client MAC Addr
–Request报文常见Opton构成:
RequestedIP addr=Must
IP Addr Lease Time=May
ClientIentifier=MayServerIdentifier=Must
ParameterRequest List=May
–BOUND
服务器收到Request报文之后,会通过ACK报文给用户正式指派一个IP地址,并进行Binding操作;如果用户请求的IP地址非法,则回应NAK;以上内容被封装到UDP:67到68报文,通过IP广播发送到指定的Client;
–ACK报文常见参数构成:
OP=2,BOOT Reply
Xid,根据Client的Request报文确定
Ciaddr=0.0.0.0或者与Request报文相同
Yiaddr=Server指定
Siaddr=BOOTP/DHCP Serv IP Addr
Giaddr=根据Request报文确定
Chaddr=Client MAC Addr
–ACK报文常见Opton构成:
RequestedIP addr=Must Not
IP Addr Lease Time=Must
ClientIentifier=Must
ServerIdentifier=Must
ParameterRequest List=Must Not
–最后客户端收到ACK报文之后,从中提取相关的IP Addr、Lease Time、Router、DNS等信息,并自动设置到自己的网卡中–DHCP基本流程就此结束,用户可以进行后续的网络访问和操作–当然,Client如果发现ACK报文异常,可以使用Decline报文进行拒绝,此时状态将回到初始INIT.
注意:DHCP Serv在正式ACK(确认信息)之前,通常需要通过Ping或者ARP报文来探测一下所分配的IP地址是否被其他主机占用!
• DHCP的扩展介绍:
–DHCP定时器
BOOTP协议中,服务器为客户主机分配完IP地址等之后,该地址将被“永久”使用,但这显然不利于有限IP资源的高效利用,所以DHCP在设计中引入了Lease Time这个租约的概念,并围绕它设置了多个定时器,以确保IP地址资源都分配给了活动的主机,不活动主机的IP地址资源将被回收再利用 Lease Time初始值通常由DHCP Serv统一指定;
–T1定时器
DHCP客户主机首先需要维护一个T1定时器,它通常是Lease Time的一半;当客户端收到服务器分配地址的T1时间之后,将自动进入Renewing状态,重新向DHCP Serv发送Request报文,用以请求/续订原IP地址的租约时间;注意该IP报文是单播给原DHCP服务器的;
–与正常Request报文的差异
相对于正常DHCP流程,Renewing状态中发起的Request报文,主要有如下几个差异:
Ciaddr=Client IP addr
Server Identifier=Must Not
服务器收到Renewing的Request报文之后,如果判定该IP地址还有效,会回应ACK报文,其中包含了一个新的Lease Time值;
–客户端收到DHCP ACK之后,提取其中的Lease Time,更新自己的定时器,同时其状态返回BOUND。–如果客户端没有收到ACK报文,则继续等待:
在后续的时间段中,每到剩余时间的一半时,就会重新发送Renewing Request报文,即分别在1/2、3/4、7/8等时发送,但两个发送的最小时间间隔不会小于一分钟;
–如果客户端在7/8租约期时的请求还没有回应,则状态自动切换到Rebinding.
–T2定时器
T2定时器就是租约期的,显然如果如果客户端的T1 Renewing更新正常的话,DHCP是不会等到T2定时器到来并进入Rebinding状态的。
只有Renewing更新不正常时,Client的才会在T2时刻进入Rebinding,并发送Request报文来续订原IP地址的租约;
–Rebinding状态中的Request报文
Rebinding状态中的Request报文,上层格式和参数方面,几乎完全相同,需要注意:
Ciaddr=Client IP addr
Server Identifier=Must Not
但该Request报文不再通过单播来发送,而是通过广播;
–客户端在T2时刻进入Rebinding状态后,如果发送的Request广播没有任何回应,会跟Renewing状态相似,每当剩余租约时间减半的时候,将重新发送续约请求,当然最小时间间隔≥60秒–如果有服务器返回ACK,即续约成功,客户端将复位自己的租约时间并重新进入到BOUND状态–如果在Lease Time完全到期之前,服务器都没有回应,Client将重新返回INIT初始状态,开始新一轮的DHCP请求。
•DHCP的REBOOT
–REBOOT
用户通过DHCP获取的IP地址虽然是“动态”的,但一般情况下为了方便日常使用,同一台主机在不同时刻请求到的IP地址尽量保持不变,用户通常缓冲上次获取的IP地址等信息,这种情况下,它在请求时,就直接通过广播发送Request报文;当然其中包含了原有的IP地址等信息;
–服务器收到这种指定IP地址(Requested IP Addr)的Request报文,会查看自己的Binding数据库,如果有匹配的条目且没有超过Lease Time,就直接通过ACK报文来分配地址;否则发送NAK;–客户端收到NAK,或者在有限时间内没有收到服务器ACK报文之后,状态将切换会初始的INIT状态;
•DHCP的释放
–DHCP的Release 如果用户离开,不再需要原有分配的IP信息时,可以通过发送Release报文给DHCP Server,这样可以让Serv端尽快的释放IP资源,而不必等到Lease Time的结束;Release报文的发送,是不期待服务器有回应的。
–Release报文常见参数构成:
OP=1,BOOT Request
Xid,由客户端确定
Ciaddr= Client IP Addr
Yiaddr=Siaddr=Giaddr=0.0.0.0
Chaddr=Client MAC Addr
–Release报文常见Opton构成:
RequestedIP addr=Must
IP Addr Lease Time=Must Not
ClientIentifier=May
ServerIdentifier=Must
ParameterRequest List=Must Not
•DHCP的中继
–DHCP-Relay,正常情况下,DHCP Client和Serv属于同一个广播域,也就是说Client发送的Discover广播能够找到Serv,只有这样,后续的Offer、Req、ACK等报文才有可能出现,但如果在多VLAN环境中,Serv和Client处于不同的广播域,情况又如何呢?这就需要开启DHCP-Relay功能;
关键:解决三层设备默认不转发广播报文的问题。
–DHCP-Relay
原理很简单,Relay设备在收到DHCP相关报文之后,如果自己本地没有DHCP服务,就将原报文通过IP单播送到指定的DHCP服务器上进行处理;从而,Client和Server之间可以间接的进行通讯;
–Option:82
Relay在将DHCP报文转发到Serv的过程中,需要添加一个Option:82选项,即Relay Agent Info Option;该Option比较特殊,它处于255(End)之前,所有其他Option之后。Option82又可包括若干sub-option,至少包含一个,其中常见的为sub-option1、sub-option2、sub-option5;
–Sub-option1
Circuit ID,通常在Relay设备上配置,用于描述Client连接交换机的对应VLAN、Port等信息;
–Sub-option2
Remote ID,也在Relay设备上面配置,用于描述中继设备的MAC地址信息;
–Sub-option5
Link Selection,用于在Option82中添加Relay设备的IP地址,Server将会根据这个IP地址分配同网段的IP地址资源给Client;
•DHCP-Snooping–DHCP-snooping
这个功能与DHCP本身并没有太多的关联,这是一种借助DHCP应用而存在的解决、防止ARP(Address Resolution Protocol)欺骗的技术手段;在预防ARP欺骗时,可以使用静态ARP绑定,这种方法虽然很高效,但实际维护起来工作量很大。
DHCP-Snooping就是一种借助于DHCP协议,来方便、自动的预防ARP欺骗的!
领取专属 10元无门槛券
私享最新 技术干货