基本介紹
- 中文名：引導程式協定
- 外文名：Bootstrap Protocol
- 縮寫：BOOTP
- 性質：一種引導協定
簡介,RFC詳解,協定的要點,包格式,雞和蛋的問題,如果客戶端知道自己的IP位址,如果客戶端還不知道自己的IP位址,ARP在客戶端使用,包處理,客戶端傳送,客戶端重傳策略,伺服器接收BOOTREQUEST（引導請求）,伺服器/網關接收BOOTREPLY（引導應答）,客戶端接收,通過網關引導,
簡介
BOOTP使用UDP報文傳輸，並使用保留連線埠號67（BOOTP伺服器）和68（BOOTP客戶端）工作。使用BOOTP協定的時候，一般包括Bootstrap Protocol Server（自舉協定服務端）和Bootstrap Protocol Client（自舉協定客戶端）兩部分。
BOOTP的一般工作流程就是BOOTP客戶端和BOOTP伺服器之間的互動，其流程如下：
- 由BOOTP啟動代碼來啟動BOOTP客戶端，這個時候BOOTP客戶端還沒有IP位址。
- BOOTP客戶端使用廣播形式的IP位址255.255.255.255向網路中發出IP位址查詢要求。
我們熟知的DHCP協定是從BOOTP的基礎上發展而來的，它們都是主機配置協定，都可以大大減少管理員的工作量。BOOTP可以看成是簡單版的DHCP，是對主機的靜態配置，而DHCP可以依據一些策略對主機進行動態配置。BOOTP用於無盤工作站的啟動和配置，而DHCP更適用於客戶端接入變化的網路，即客戶端接入時間、接入地點不固定。
RFC詳解
本RFC描述第一個階段：'分配地址和選擇引導檔案'。
在獲得地址和檔案名稱信息後，就進入引導的第二個階段：檔案傳送。
檔案傳送一般使用TFTP協定[9]，因為兩個階段均駐留在客戶端的PROM中。
但BOOTP也能夠與其它協定如SFTP或FTP一起工作。
這是一種無人值守的上電啟動方式。
必須提供一種機制來讓用戶手工提供地址和檔案名稱信息旁路BOOTP協定直接進入檔案傳送
階段。
如果提供非可變存儲，我們建議在那裡保存設定以旁路BOOTP協定直到這些設定導致檔案
傳送階段失敗。
如果快取的信息失敗，引導後退到第一階段並使用BOOTP。
協定的要點
1．使用了一個單獨的包交換（信息）。使用逾時機制直到收到應答。
雙向使用相同的包欄位結構。使用（最大可能長度的）固定長度的欄位來簡化結構定義
和分析。
2．一個'opcode'欄位包含兩個值。客戶端廣播一個'引導請求(bootrequest)'包。
還包含它的IP位址。
或伺服器在一個遠距離的網路/域。）
4．請求可以包含'通用(generic)'引導檔案名稱。例如'unix'或'ethertip'。但伺服器傳送
引導應答時，它使用對應的引導檔案的確切的路徑名稱來取代這個欄位。
伺服器查詢客戶端的地址和請求檔案名稱相關的資料庫，以使用客戶端自定義的特定引導
檔案確定這個檔案名稱稱。
欄位。
5．客戶端不知道它們的IP位址的情況下，
伺服器必須有一個硬體地址和IP位址對應的資料庫。
這個客戶端IP位址被放在引導應答的（對應）欄位中。
6．某些網路拓樸（如斯坦福的網路）可能在一個物理網上沒有一個直接可以訪問的TFTP
引導'的章節。
這部分協定不需求客戶端部分做特定的動作。
包格式
除非另外指出，所有顯示的數字都是十進制的。
簡化起見，假設BOOTP包不會被分片。
所有數字的欄位使用標準網路位元組順序。即，先傳送高位比特。
道時，
IP目的地址將是廣播地址255.255.255.255。這個地址意味著'在本地網上廣播，我不知道我的
網路號'[4]。
和'BOOTP伺服器'(67)。
能是也可能不是廣播
（在下面'雞和蛋的問題'標題的章節中深入解釋）。
務器進程。
所有進入的廣播報文將在核心級別過濾掉。
是廣播，
UDP長度欄位設定成UDP長度加BOOTP部分的包。
在下面的'包處理'章節中'[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
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能夠正常傳送。
如果客戶端還不知道自己的IP位址
（ciaddr是零），
客戶端就不能回應引導應答傳送程式回的ARPs。這時有兩種選擇：
a.如果傳送程式有必需的核心或驅動鉤子程式來人工建立ARP地址緩衝條目，
就可以使用'chaddr'和'yiaddr'欄位填入一個條目。當然，這個條目象正常ARP建立的
其它條目一樣有一個生命時間，
引導應答的傳送程式就能夠簡單地傳送引導應答到客戶端的IP位址了。UNIX(4.2
BSD)有這種功能。
b.如果傳送程式缺少這些核心鉤子程式，就只能簡單傳送引導應答到相應接口的廣播
地址。
這只是在前面情況外的額外的廣播。
ARP在客戶端使用
客戶端PROM必須包含一個ARP的簡單實現，例如，地址緩衝能夠容納一個條目。
這將允許客戶端在知道IP位址和引導檔案名稱後執行第二階段引導（TFTP）。
TFTP或BOOTP應答。
但這應該只是一種特殊情況，因為上面描述的只有第二階段的引導仍然允許。
己的IP位址。
但RARP的劣勢是它是一個硬體鏈路層的協定（不是基於IP/UDP）。
因為存在不同組織維護的許多網路核心，一個不要求修改核心的引導協定是一個確定
的優勢。
BOOTP除了上述章節描述的有用的特性外，還提供硬體到IP位址的查詢功能。
包處理
客戶端傳送
在第一次建立包前，最好把整個包的緩衝區清零；
這將所有的欄位設定成默認狀態。任何客戶端建立包中的下列欄位。
IP源地址和'ciaddr'設定成客戶端IP位址（如果知道），或者0。UDP頭使用適當的長度設
置；
'op'設定成'1'，BOOTREQUEST（引導請求）。'htype'設定成在"Assigned
Numbers"RFCARP章節中分配的硬體地址類型。
'hlen'設定成硬體地址長度，例如，10M乙太網是'6'。
'xid'設定成一個'隨機'事務ID。'secs'設定成客戶端引導開始後過去的秒數。
這個讓伺服器知道客戶端已經試了多長時間了。
或者它可以選擇簡單傳送使用一個固定值如100秒的欄位。
如果客戶端知道IP位址，'ciaddr'（和IP源地址）設定成這個值。
'chaddr'使用客戶端硬體地址填寫。
串。
使用的名字應該是對應的主機的正當的名字或別名。
客戶端在填寫'file'檔案名稱欄位是有許多選擇。
如果設定成空，意味著'我向使用默認的檔案來引導我的機器'。一個空檔案名稱也意味著
這個欄位也可以是一個'通用'名字入'unix'或'gateway'；這意味著
'使用命名的程式配置來引導我的機器'。最後這個欄位可以是確切的目錄路徑名字。
'vend'欄位可以由客戶端填寫賣主的字元串或結構。例如可以填寫機器硬體類型或序列
號。
但BOOTP伺服器的操作應該不依賴與這些存在的信息。
如果使用了'vend'，推薦在'vend'中第一個項目為一個4位元組的'魔術字(magicnumber)'。
這讓伺服器確定在這個欄位中它看到什麼類型的信息。
數值可以由通常的'魔術字'過程分配，你挑一個，它就成為魔術字。
作。
[UDP校驗和]
客戶端重傳策略
在一長段時間內沒有收到應答，客戶端應該重傳請求。
時間間隔必須仔細選擇不要引起網路風暴。
可以考慮一個包含100台機器的網路在電源故障後發生的情況。
簡單的每四秒重傳請求將淹沒網路。
一個可能的策略，你可能考慮指數級的補償，象乙太網在碰撞時那樣。
例如第一個包在0:00，第二個在:04，接著：08，接著：16，：32，：64。
你應該隨機化每個時間；這就象乙太網規格那樣以一個掩碼'與'一個隨機數進入第一次補
償。
在每次後續的補償中，掩碼增長一個比特。
這樣在每次補償中平均延遲加倍。
在'平均'補償到達60秒後，就不再增長了，但仍然隨機化。
在每次重傳前，客戶端應該修改'secs'欄位。[UDP校驗和]
伺服器接收BOOTREQUEST（引導請求）
如果伺服器名字欄位(sname)是空（沒有指定特定的伺服器），或者sname是指定的並且
匹配我們的名字或別名，
繼續包的處理。
如果sname欄位是指定的，但不匹配'我們'，那么有多種選擇：
1．你可以選擇簡單丟棄這個包。
2．如果查詢sname的名稱顯示它在一個網路中，丟棄這個包。
3．如果sname在不同的網路中，你可以選擇轉發這個包到那個地址。
如果這樣，檢查'giaddr'(網關地址）欄位。如果'giaddr'是0，填入我的地址或可以用來
到達那個網路的網關的地址。
然後轉發這個包。
如果客戶端IP位址（ciaddr）是0，那么客戶端不知道自己的IP位址。
嘗試在我們的資料庫中查找客戶端的硬體地址(chaddr,hlen,htype)。
如果沒有匹配，丟棄這個包。否則我們對這個客戶端有一個IP位址；填入'yiaddr'（你
的IP位址）欄位。
這個欄位是空。
如果這個欄位非空，可以將它和客戶端的IP位址做為資料庫的查詢關鍵字。
如果有默認的檔案或通用檔案（可能由客戶端地址做為索引）或一個匹配的指定的路徑
名稱，
然後在'file'欄位中填入選擇的引導檔案的指定的路徑名稱。
如果欄位是非空並且沒有匹配，那么客戶端要一個我們沒有的檔案，丟棄這個包，也許
其它BOOTP伺服器有這個檔案。
賣主指定的數據欄位'vend'應該檢查了。如果提供一種可識別類型的數據，
應該進行客戶端指定的動作，並且回應要填入應答包中的'vend'數據欄位。
限，
或一套配置選項傳給馬上就要引導入的作業系統。
我的（伺服器）IP位址填入'siaddr'欄位。設定'op'欄位為BOOTREPLY（引導應答）。
'giaddr'。
否則客戶端在我們的一個網路中但它還不知道自己的IP位址，使用在上面'蛋'章節中描述
的方法來傳送它到客戶端。
如果使用'蛋'並且我們在主機上有許多接口，使用'yiaddr'（你的IP位址）欄位指出傳送包
到哪個網路（網路/接口）。
[UDP校驗和]
伺服器/網關接收BOOTREPLY（引導應答）
[UDP校驗和]如果'yiaddr'(你的[客戶端的]IP位址)指向我們的一個網路，使用上述'蛋'方
法來將它轉發到客戶端。
確認將它傳送到'BOOTP客戶端'UDP目的連線埠。
客戶端接收
不要忘記為我自己的IP位址（如果我知道）處理ARP請求。[UDP校驗和]
導應答）；
不匹配我的IP位址（如果我知道）或我的硬體地址；不匹配我的事務ID。
否則我們就收到一個成功的應答。如果我以前不知道的話，'yiaddr'包含我的IP位址。
那么包應該先轉發到那裡，然後到達伺服器。
通過網關引導
帶盤網關（例如，一個做為網關的UNIX機器）可能運行它們自己的BOOTP/TFTP伺服器。
偵聽BOOTREQUEST（引導請求）廣播的網關可能確定轉發還是適當地再廣播這些請求。
例如，做為配置表格的一部分，網關可以有一個接收任意BOOTREQUEST（引導請求）廣
播的其它網路或主機的列表。
即使考慮有一個'hops'欄位，簡單全部再廣播請求仍是一個差的方法，因為廣播循環幾乎肯
定會發生。
轉發可以立即開始，或等'secs'（客戶端嘗試的秒數）欄位超過某個閥值。
如果一個網關確定轉發請求，它應該查看'giaddr'（網關IP位址）欄位。
如果是0，它就在這個欄位中加入自己的IP位址（在接收的網路中）。
也可以使用'hops'欄位來可選控制包可以轉發多遠。每次轉發應該增加跳數。
例如，如果跳數超過'3'，包應該被丟棄。
[UDP校驗和]
這裡我們推薦在網關中增加這個特殊的轉發功能。
但不總是這樣子的。
在網上存在一些'BOOTP轉發代理'引導客戶端，這些代理可以適當地轉發。
這樣這些服務可以和網關在一起，也可以不在一起。
當轉發代理不和網關在一起時，代理可以通過在接收的引導請求中'giaddr'欄位加上接口的廣
播地址節省一些工作。
這樣應答就可以使用普通的網關來轉發，而不包含轉發代理。
的額外的花費。
