標籤: 暫無標籤

自舉協議(BOOTP)是一個基於IP/UDP協議的協議,它可以讓無盤站從一個中心伺服器上獲得IP地址,為區域網中的無盤工作站分配動態IP地址,並不需要每個用戶去設置靜態IP地址。使用BOOTP協議的時候,一般包括Bootstrap Protocol Server(自舉協議服務端)和Bootstrap Protocol Client(自舉協議客戶端)兩部分。

1對照語義

中文釋義
自舉協議

2應用

該協議主要用於有無盤工作站的區域網中,客戶端獲取IP地址的過程如下:首先,由BOOTP啟動代碼啟動客戶端,這個時候客戶端還沒有IP地址,使用廣播形式以IP地址255.255.255.255向網路中發出IP地址查詢要求。接著,運行BOOTP協議的伺服器接收到這個請求,會根據請求中提供的MAC地址找到客戶端,併發送一個含有IP地址、伺服器IP地址、網關等信息的FOUND幀。最後,客戶端會根據該FOUND幀來通過專用TFTP伺服器下載啟動鏡像文件,模擬成磁碟啟動。

3RFC詳解

本RFC描述一種IP/UDP引導協議(BOOTP),允許一個無盤客戶端發現自己的IP地址,
伺服器主機的地址,和裝入一個指定名稱的文件到內存並且運行。引導操作有兩階段組成。
本RFC描述第一個階段:'分配地址和選擇引導文件'。
在獲得地址和文件名信息后,就進入引導的第二個階段:文件傳送。
文件傳送一般使用TFTP協議[9],因為兩個階段均駐留在客戶端的PROM中。
但BOOTP也能夠與其它協議如SFTP或FTP一起工作。
我們建議客戶端的PROM軟體提供一種無須用戶交互的完整的引導方式。
這是一種無人值守的上電啟動方式。
必須提供一種機制來讓用戶手工提供地址和文件名信息旁路BOOTP協議直接進入文件傳送
階段。
如果提供非可變存儲,我們建議在那裡保存設置以旁路BOOTP協議直到這些設置導致文件
傳送階段失敗。
如果緩存的信息失敗,引導後退到第一階段並使用BOOTP。
包格式
除非另外指出,所有顯示的數字都是十進位的。
簡化起見,假設BOOTP包不會被分片。
所有數字的欄位使用標準網路位元組順序。即,先傳送高位比特。
在引導請求的IP頭中,客戶端如果知道就填自己的IP源地址,否則填0。當伺服器地址不知
道時,
IP目的地址將是廣播地址255.255.255.255。這個地址意味著'在本地網上廣播,我不知道我的
網路號'[4]。
UDP頭包含源和目的埠號。BOOTP協議使用兩個保留的埠號,'BOOTP客戶端'(68)
和'BOOTP伺服器'(67)。
客戶使用'BOOTP伺服器'作為目的埠發送請求;這通常是廣播。
伺服器使用'BOOTP客戶端'做為目的埠發送應答;取決於伺服器的核心或驅動設備,這可
能是也可能不是廣播
(在下面'雞和蛋的問題'標題的章節中深入解釋)。
使用兩個保留的埠的原因是當引導應答必須廣播到客戶端避免'叫醒'並且調度BOOTP服
務器進程。
因為伺服器和其它主機都不會偵聽'BOOTP客戶端'埠,
所有進入的廣播報文將在核心級別過濾掉。
我們不能簡單地允許客戶端找一個隨機埠號做為UDP源埠欄位;因為伺服器應答可能
是廣播,
一個隨機選擇的埠號可能搞亂其它恰巧在偵聽那個埠的主機。
UDP長度欄位設置成UDP長度加BOOTP部分的包。
UDP校驗和可以由客戶端(或伺服器)按照需要設置成0,以避免PROM實現中額外的費用。
在下面的'包處理'章節中'[UDP校驗和]'短語用來表示校驗和可能被驗證/計算。
欄位位元組數 描述
----- ----- -----------
op 1 packet op code / message type. 包操作碼/消息類型
1.= BOOTREQUEST(引導請求),2 = BOOTREPLY(引導應答)
htype 1 hardware address type,硬體地址類型
see ARP section in "Assigned Numbers" RFC. 請看"Assigned Numbers" RFC中的ARP章節
'1' = 10mb ethernet 10M乙太網
hlen 1 hardware address length 硬體地址長度
(eg '6' for 10mb ethernet). 例如'6'是10M乙太網
hops 1 client sets to zero,客戶端設置成0
optionally used by gateways 在跨越網關引導時網關可選擇使用
in cross-gateway booting.
xid 4 transaction ID,a random number,
used to match this boot request with the
responses it generates.事務ID,一個隨機數,用來匹配引用請求和應答
secs 2 filled in by client,seconds elapsed since
client started trying to boot.由客戶端填寫,客戶端引導開始后的過去的秒數
-- 2 unused未使用
ciaddr4 client IP address;客戶端IP地址,
filled in by client in bootrequest if known.如果客戶端知道就在引導請求中填入
yiaddr4 'your' (client) IP address;'你的'(客戶端)IP地址
filled by server if client doesn't
know its own address (ciaddr was 0).如果客戶端不知道它的地址(ciaddr是0),伺服器填入
siaddr4 server IP address;伺服器IP地址
returned in bootreply by server.由伺服器在引導應答返回
giaddr4 gateway IP address,網關IP地址
used in optional cross-gateway booting.在跨越網關引導中可以選擇使用
chaddr16 client hardware address,客戶端硬體地址
filled in by client.由客戶端填寫
sname 64 optional server host name,可選的伺服器主機名
null terminated string. 空結束的字元串
file 128 boot file name,null terminated string; 引導文件名,空結束的字元串
'generic' name or null in bootrequest,在引導請求中使用'通用'名稱或空
fully qualified directory-path 是引導應答中使用確切的目錄路徑名稱
name in bootreply.
vend 64 optional vendor-specific area,可選的賣主指定的區域,
e.g. could be hardware type/serial on request,例如,可以是請求硬體類型/序列,
or 'capability' / remote file system handle 或應答的性能/遠端文件系統句柄。
on reply.This info may be set aside for use這些信息留給第三方分析引導或核心(程序)使用。
by a third phase bootstrap or kernel.
如果客戶端知道自己的IP地址
('ciaddr'欄位非零),
因為客戶端能夠回應ARPs[5],那麼IP能夠正常發送。
ARP在客戶端使用
客戶端PROM必須包含一個ARP的簡單實現,例如,地址緩衝能夠容納一個條目。
這將允許客戶端在知道IP地址和引導文件名后執行第二階段引導(TFTP)。
任何時候客戶端應該準備回應一個自己IP到硬體地址映射的ARP請求(如果知道)以接收
TFTP或BOOTP應答。
因為引導應答將包含伺服器/網關的硬體源地址(在硬體中封裝),客戶端可以
避免發送一條ARP請求來申請後續的TFTP階段使用的伺服器/網關IP地址。
但這應該只是一種特殊情況,因為上面描述的只有第二階段的引導仍然允許。
與RARP對照 提議客戶端使用一個早先的協議,反向地址解析協議(RARP)[1]來通過它的硬體地址確定自
己的IP地址。
但RARP的劣勢是它是一個硬體鏈路層的協議(不是基於IP/UDP)。
這意味著RARP只能在包含特殊的為訪問原始報文修改的核心和驅動的主機上實現。
因為現在存在不同組織維護的許多網路核心,一個不要求修改核心的引導協議是一個確定
的優勢。
BOOTP除了上述章節描述的有用的特性外,還提供硬體到IP地址的查詢功能。

4包處理

2,客戶端重傳策略
在一長段時間內沒有收到應答,客戶端應該重傳請求。
時間間隔必須仔細選擇不要引起網路風暴。
可以考慮一個包含100台機器的網路在電源故障后發生的情況。
簡單的每四秒重傳請求將淹沒網路。
一個可能的策略,你可能考慮指數級的補償,象乙太網在碰撞時那樣。
例如第一個包在0:00,第二個在:04,接著:08,接著:16,:32,:64。
你應該隨機化每個時間;這就象乙太網規格那樣以一個掩碼'與'一個隨機數進入第一次補
償。
在每次後續的補償中,掩碼增長一個比特。
這樣在每次補償中平均延遲加倍。
在'平均'補償到達60秒后,就不再增長了,但仍然隨機化。
在每次重傳前,客戶端應該修改'secs'欄位。[UDP校驗和]
4,伺服器/網關接收BOOTREPLY(引導應答)
[UDP校驗和]如果'yiaddr'(你的[客戶端的]IP地址)指向我們的一個網路,使用上述'蛋'方
法來將它轉發到客戶端。
確認將它傳送到'BOOTP客戶端'UDP目的埠。
通過網關引導
這部分協議是可選的並要求許多網關和伺服器配合的額外的代碼,但它允許跨越網關引導。
這主要在網關是無盤機器時有用。
帶盤網關(例如,一個做為網關的UNIX機器)可能運行它們自己的BOOTP/TFTP伺服器。
偵聽BOOTREQUEST(引導請求)廣播的網關可能確定轉發還是適當地再廣播這些請求。
例如,做為配置表格的一部分,網關可以有一個接收任意BOOTREQUEST(引導請求)廣
播的其它網路或主機的列表。
即使考慮有一個'hops'欄位,簡單全部再廣播請求仍是一個差的方法,因為廣播循環幾乎肯
定會發生。
轉發可以立即開始,或等'secs'(客戶端嘗試的秒數)欄位超過某個閥值。
如果一個網關確定轉發請求,它應該查看'giaddr'(網關IP地址)欄位。
如果是0,它就在這個欄位中加入自己的IP地址(在接收的網路中)。
也可以使用'hops'欄位來可選控制包可以轉發多遠。每次轉發應該增加跳數。
例如,如果跳數超過'3',包應該被丟棄。
[UDP校驗和]
這裡我們推薦在網關中增加這個特殊的轉發功能。
但不總是這樣子的。
在網上存在一些'BOOTP轉發代理'引導客戶端,這些代理可以適當地轉發。
這樣這些服務可以和網關在一起,也可以不在一起。
當轉發代理不和網關在一起時,代理可以通過在接收的引導請求中'giaddr'欄位加上介面的廣
播地址節省一些工作。
這樣應答就可以使用普通的網關來轉發,而不包含轉發代理。
當然劣勢是你失去了使用'蛋'非廣播方式來發送應答的能力,導致在客戶端網上的每個主機
的額外的花費。
下一篇[MIME]

相關評論

同義詞:暫無同義詞