智能物聯 聯網ip地址 設備標識
由於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 Request?Xid＝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 Reply?Xid，由Client的Discover報文確定;
?Ciaddr＝0.0.0.0?Yiaddr＝Offered IP Addr，由Server確定;
?Siaddr＝BOOTP/DHCPServ IP Addr?Giaddr，由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＝May?ServerIdentifier＝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欺騙的!
TAG:都市物聯 |