bootp

   

   英文原義：Bootstrap Protocol

中文釋義：自舉協(xié)議

注解：該協(xié)議是一個基于TCP/IP協(xié)議的協(xié)議，它可以讓無盤站從一個中心服務器上獲得IP地址，為局域網(wǎng)中的無盤工作站分配動態(tài)IP地址，并不需要每個用戶去設置靜態(tài)IP地址。使用BOOTP協(xié)議的時候，一般包括Bootstrap Protocol Server（自舉協(xié)議服務端）和Bootstrap Protocol Client（自舉協(xié)議客戶端）兩部分。

應    用：該協(xié)議主要用于有無盤工作站的局域網(wǎng)中，客戶端獲取IP地址的過程如下：首先，由BOOTP啟動代碼啟動客戶端，這個時候客戶端還沒有IP地址，使用廣播形式以IP地址0.0.0.0向網(wǎng)絡中發(fā)出IP地址查詢要求。接著，運行BOOTP協(xié)議的服務器接收到這個請求，會根據(jù)請求中提供的MAC地址找到客戶端，并發(fā)送一個含有IP地址、服務器IP地址、網(wǎng)關等信息的FOUND幀。最后，客戶端會根據(jù)該FOUND幀來通過專用TFTP服務器下載啟動鏡像文件，模擬成磁盤啟動。


本RFC描述一種IP/UDP引導協(xié)議(BOOTP)，允許一個無盤客戶端發(fā)現(xiàn)自己的IP地址，
服務器主機的地址，和裝入一個指定名稱的文件到內(nèi)存并且運行。引導操作有兩階段組成。
本RFC描述第一個階段：&＃039;分配地址和選擇引導文件&＃039;。
在獲得地址和文件名信息后，就進入引導的第二個階段：文件傳送。
文件傳送一般使用TFTP協(xié)議[9]，因為兩個階段均駐留在客戶端的PROM中。
但BOOTP也能夠與其它協(xié)議如SFTP或FTP一起工作。
我們建議客戶端的PROM軟件提供一種無須用戶交互的完整的引導方式。
這是一種無人值守的上電啟動方式。
必須提供一種機制來讓用戶手工提供地址和文件名信息旁路BOOTP協(xié)議直接進入文件傳送
階段。
如果提供非可變存儲，我們建議在那里保存設置以旁路BOOTP協(xié)議直到這些設置導致文件
傳送階段失敗。
如果緩存的信息失敗，引導后退到第一階段并使用BOOTP。
協(xié)議的要點：
1.使用了一個單獨的包交換（信息）。使用超時機制直到收到應答。
雙向使用相同的包字段結(jié)構(gòu)。使用（最大可能長度的）固定長度的字段來簡化結(jié)構(gòu)定義
和分析。
2.一個&＃039;opcode&＃039;字段包含兩個值�？蛻舳藦V播一個&＃039;引導請求(bootrequest)&＃039;包。
服務器應答一個&＃039;引導應答(bootreply)&＃039;包。&＃039;bootrequest&＃039;包含客戶端的硬件地址，如果知道，
還包含它的IP地址。
3.請求可以包含客戶端指定的響應服務器的名稱。
這樣客戶端可以強制從一個指定的主機引導。（如果一個相同的引導文件存在多種版本
或服務器在一個遠距離的網(wǎng)絡/域。）
客戶端不必處理名稱/域服務，這個功能推到了BOOTP服務器。
4.請求可以包含&＃039;通用(generic)&＃039;引導文件名。例如&＃039;unix&＃039;或&＃039;ethertip&＃039;。但服務器發(fā)送
引導應答時，它使用對應的引導文件的確切的路徑名稱來取代這個字段。
服務器查詢客戶端的地址和請求文件名相關的數(shù)據(jù)庫，以使用客戶端自定義的特定引導
文件確定這個文件名稱。
如果引導請求文件名是空字符串，服務器返回一個帶有客戶端加載的默認文件的文件名
字段。
5.客戶端不知道它們的IP地址的情況下，
服務器必須有一個硬件地址和IP地址對應的數(shù)據(jù)庫。
這個客戶端IP地址被放在引導應答的（對應）字段中。
6.某些網(wǎng)絡拓樸（如斯坦福的網(wǎng)絡）可能在一個物理網(wǎng)上沒有一個直接可以訪問的TFTP
服務器
（例如在某些網(wǎng)上的所有的網(wǎng)關和主機都可能是無盤的）。
BOOTP允許客戶端通過使用相鄰的網(wǎng)關從幾跳外的服務器上引導。請看下面&＃039;通過網(wǎng)關
引導&＃039;的章節(jié)。
這部分協(xié)議不需求客戶端部分做特定的動作。
實現(xiàn)是可選的，網(wǎng)關和服務器需要一些額外的代碼。
2 包格式
除非另外指出，所有顯示的數(shù)字都是十進制的。
簡化起見，假設BOOTP包不會被分片。
所有數(shù)字的字段使用標準網(wǎng)絡字節(jié)順序。即，先傳送高位比特。
在引導請求的IP頭中，客戶端如果知道就填自己的IP源地址，否則填0。當服務器地址不知
道時，
IP目的地址將是廣播地址255.255.255.255。這個地址意味著&＃039;在本地網(wǎng)上廣播，我不知道我的
網(wǎng)絡號&＃039;[4]。
UDP頭包含源和目的端口號。BOOTP協(xié)議使用兩個保留的端口號，&＃039;BOOTP客戶端&＃039;(68)
和&＃039;BOOTP服務器&＃039;(67)。
客戶使用&＃039;BOOTP服務器&＃039;做為目的端口發(fā)送請求；這通常是廣播。
服務器使用&＃039;BOOTP客戶端&＃039;做為目的端口發(fā)送應答；取決于服務器的核心或驅(qū)動設備，這可
能是也可能不是廣播
（在下面&＃039;雞和蛋的問題&＃039;標題的章節(jié)中深入解釋）。
使用兩個保留的端口的原因是當引導應答必須廣播到客戶端避免&＃039;叫醒&＃039;并且調(diào)度BOOTP服
務器進程。
因為服務器和其它主機都不會偵聽&＃039;BOOTP客戶端&＃039;端口，
所有進入的廣播報文將在核心級別過濾掉。
我們不能簡單地允許客戶端找一個隨機端口號做為UDP源端口字段；因為服務器應答可能
是廣播，
一個隨機選擇的端口號可能搞亂其它恰巧在偵聽那個端口的主機。
UDP長度字段設置成UDP長度加BOOTP部分的包。
UDP校驗和可以由客戶端（或服務器）按照需要設置成0，以避免PROM實現(xiàn)中額外的費用。
在下面的&＃039;包處理&＃039;章節(jié)中&＃039;[UDP校驗和]&＃039;短語用來表示校驗和可能被驗證/計算。
       字段  字節(jié)數(shù) 描述
       -----   -----   -----------

          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章節(jié)
                          &＃039;1&＃039; = 10mb ethernet 10M以太網(wǎng)

          hlen    1       hardware address length 硬件地址長度
                          (eg &＃039;6&＃039; for 10mb ethernet). 例如&＃039;6&＃039;是10M以太網(wǎng)

          hops    1       client sets to zero, 客戶端設置成0
                          optionally used by gateways   在跨越網(wǎng)關引導時網(wǎng)關可選擇使用
                          in cross-gateway booting.

          xid     4       transaction ID, a random number,
                          used to match this boot request with the
                          responses it generates.  事務ID，一個隨機數(shù)，用來匹配引用請求和應答

          secs    2       filled in by client, seconds elapsed since
                          client started trying to boot.  由客戶端填寫，客戶端引導開始后的過去的秒數(shù)

          --      2       unused未使用

          ciaddr  4       client IP address;客戶端IP地址，
                          filled in by client in bootrequest if known.如果客戶端知道就在引導請求中填入

          yiaddr  4       &＃039;your&＃039; (client) IP address;&＃039;你的&＃039;（客戶端）IP地址
                          filled by server if client doesn&＃039;t
                          know its own address (ciaddr was 0).如果客戶端不知道它的地址(ciaddr是0），服務器填入

          siaddr  4       server IP address;服務器IP地址
                          returned in bootreply by server.由服務器在引導應答返回

          giaddr  4       gateway IP address,網(wǎng)關IP地址
                          used in optional cross-gateway booting.在跨越網(wǎng)關引導中可以選擇使用

          chaddr  16      client hardware address,客戶端硬件地址
                          filled in by client.由客戶端填寫

          sname   64      optional server host name,可選的服務器主機名
                          null terminated string. 空結(jié)束的字符串

          file    128     boot file name, null terminated string; 引導文件名，空結(jié)束的字符串
                          &＃039;generic&＃039; name or null in bootrequest, 在引導請求中使用&＃039;通用&＃039;名稱或空
                          fully qualified directory-path         是引導應答中使用確切的目錄路徑名稱
                          name in bootreply.

          vend    64      optional vendor-specific area,  可選的賣主指定的區(qū)域，
                          e.g. could be hardware type/serial on request, 例如，可以是請求硬件類型/序列，
                          or &＃039;capability&＃039; / remote file system handle    或應答的性能/遠端文件系統(tǒng)句柄。
                          on reply.  This info may be set aside for use  這些信息留給第三方分析引導或核心（程序）使用。
                          by a third phase bootstrap or kernel.
3 雞和蛋的問題
如果客戶端不知道自己IP地址，服務器怎么發(fā)送IP報文到客戶端。
無論何時一條引導應答被發(fā)送，發(fā)送設備執(zhí)行下列操作：
1.如果客戶端知道自己的IP地址（&＃039;ciaddr&＃039;字段非零），
因為客戶端能夠回應ARPs[5]，那么IP能夠正常發(fā)送。
2.如果客戶端還不知道自己的IP地址（ciaddr是零），
客戶端就不能回應引導應答發(fā)送程序回的ARPs。這時有兩種選擇：
a.如果發(fā)送程序有必需的核心或驅(qū)動鉤子程序來人工建立ARP地址緩沖條目，
就可以使用&＃039;chaddr&＃039;和&＃039;yiaddr&＃039;字段填入一個條目。當然，這個條目象正常ARP建立的
其它條目一樣有一個生命時間，
引導應答的發(fā)送程序就能夠簡單地發(fā)送引導應答到客戶端的IP地址了。UNIX(4.2
BSD)有這種功能。
b.如果發(fā)送程序缺少這些核心鉤子程序，就只能簡單發(fā)送引導應答到相應接口的廣播
地址。
這只是在前面情況外的額外的廣播。
4 ARP在客戶端使用
客戶端PROM必須包含一個ARP的簡單實現(xiàn)，例如，地址緩沖能夠容納一個條目。
這將允許客戶端在知道IP地址和引導文件名后執(zhí)行第二階段引導（TFTP）。
任何時候客戶端應該準備回應一個自己IP到硬件地址映射的ARP請求（如果知道）以接收
TFTP或BOOTP應答。
因為引導應答將包含服務器/網(wǎng)關的硬件源地址（在硬件中封裝），客戶端可以
避免發(fā)送一條ARP請求來申請后續(xù)的TFTP階段使用的服務器/網(wǎng)關IP地址。
但這應該只是一種特殊情況，因為上面描述的只有第二階段的引導仍然允許。
5 與RARP對照
提議客戶端使用一個早先的協(xié)議，反向地址解析協(xié)議(RARP)[1]來通過它的硬件地址確定自
己的IP地址。
但RARP的劣勢是它是一個硬件鏈路層的協(xié)議（不是基于IP/UDP）。
這意味著RARP只能在包含特殊的為訪問原始報文修改的核心和驅(qū)動的主機上實現(xiàn)。
因為現(xiàn)在存在不同組織維護的許多網(wǎng)絡核心，一個不要求修改核心的引導協(xié)議是一個確定
的優(yōu)勢。
BOOTP除了上述章節(jié)描述的有用的特性外，還提供硬件到IP地址的查詢功能。
6 包處理
6.1客戶端傳送
在第一次建立包前，最好把整個包的緩沖區(qū)清零；
這將所有的字段設置成默認狀態(tài)。任何客戶端建立包中的下列字段。
IP目的地址被設置成255.255.255.255（廣播地址）或服務器的IP地址（如果知道）。
IP源地址和&＃039;ciaddr&＃039;設置成客戶端IP地址（如果知道），或者0。UDP頭使用適當?shù)拈L度設
置；
源端口=&＃039;BOOTP客戶端&＃039;端口，目標端口=&＃039;BOOTP服務器&＃039;端口。
&＃039;op&＃039;設置成&＃039;1&＃039;，BOOTREQUEST（引導請求）。&＃039;htype&＃039;設置成在"Assigned
Numbers"RFCARP章節(jié)中分配的硬件地址類型。
&＃039;hlen&＃039;設置成硬件地址長度，例如，10M以太網(wǎng)是&＃039;6&＃039;。
&＃039;xid&＃039;設置成一個&＃039;隨機&＃039;事務ID。&＃039;secs&＃039;設置成客戶端引導開始后過去的秒數(shù)。
這個讓服務器知道客戶端已經(jīng)試了多長時間了。
當數(shù)字變大，某些服務器可能更多注意這個客戶端提供不同的服務。
如果客戶端缺少一個適當?shù)臅r鐘，它可以使用循環(huán)定時器建立一個粗略的估計值。
或者它可以選擇簡單發(fā)送使用一個固定值如100秒的字段。
如果客戶端知道IP地址，&＃039;ciaddr&＃039;（和IP源地址）設置成這個值。
&＃039;chaddr&＃039;使用客戶端硬件地址填寫。
如果客戶端希望限制從一個特定服務器名引導，就可以在&＃039;sname&＃039;中放一個空結(jié)束的字符
串。
使用的名字應該是對應的主機的正當?shù)拿�字或別名。
客戶端在填寫&＃039;file&＃039;文件名字段是有許多選擇。
如果設置成空，意味著&＃039;我向使用默認的文件來引導我的機器&＃039;。一個空文件名也意味著
&＃039;我只對找到客戶端/服務器/網(wǎng)關的IP地址感興趣，我不在乎文件名&＃039;。
這個字段也可以是一個&＃039;通用&＃039;名字入&＃039;unix&＃039;或&＃039;gateway&＃039;；這意味著
&＃039;使用命名的程序配置來引導我的機器&＃039;。最后這個字段可以是確切的目錄路徑名字。
&＃039;vend&＃039;字段可以由客戶端填寫賣主的字符串或結(jié)構(gòu)。例如可以填寫機器硬件類型或序列
號。
但BOOTP服務器的操作應該不依賴與這些存在的信息。
如果使用了&＃039;vend&＃039;，推薦在&＃039;vend&＃039;中第一個項目為一個4字節(jié)的&＃039;魔術(shù)字(magicnumber)&＃039;。
這讓服務器確定在這個字段中它看到什么類型的信息。
數(shù)值可以由通常的&＃039;魔術(shù)字&＃039;過程分配，你挑一個，它就成為魔術(shù)字。
引導應答使用一個與引導請求不同的魔術(shù)字以允許客戶端按照應答信息進行特殊的動
作。
[UDP校驗和]
6.2客戶端重傳策略
在一長段時間內(nèi)沒有收到應答，客戶端應該重傳請求。
時間間隔必須仔細選擇不要引起網(wǎng)絡風暴。
可以考慮一個包含100臺機器的網(wǎng)絡在電源故障后發(fā)生的情況。
簡單的每四秒重傳請求將淹沒網(wǎng)絡。
一個可能的策略，你可能考慮指數(shù)級的補償，象以太網(wǎng)在碰撞時那樣。
例如第一個包在0:00，第二個在:04，接著:08，接著:16，:32，:64。
你應該隨機化每個時間；這就象以太網(wǎng)規(guī)格那樣以一個掩碼&＃039;與&＃039;一個隨機數(shù)進入第一次補
償。
在每次后續(xù)的補償中，掩碼增長一個比特。
這樣在每次補償中平均延遲加倍。
在&＃039;平均&＃039;補償?shù)竭_60秒后，就不再增長了，但仍然隨機化。
在每次重傳前，客戶端應該修改&＃039;secs&＃039;字段。[UDP校驗和]
6.3服務器接收BOOTREQUEST（引導請求）
[UDP校驗和]如果UDP目的端口不匹配&＃039;BOOTP服務器&＃039;端口，丟棄這個包。
如果服務器名字字段(sname)是空（沒有指定特定的服務器），或者sname是指定的并且
匹配我們的名字或別名，
繼續(xù)包的處理。
如果sname字段是指定的，但不匹配&＃039;我們&＃039;，那么有多種選擇：
1.你可以選擇簡單丟棄這個包。
2.如果查詢sname的名稱顯示它在一個網(wǎng)絡中，丟棄這個包。
3.如果sname在不同的網(wǎng)絡中，你可以選擇轉(zhuǎn)發(fā)這個包到那個地址。
如果這樣，檢查&＃039;giaddr&＃039;(網(wǎng)關地址）字段。如果&＃039;giaddr&＃039;是0，填入我的地址或可以用來
到達那個網(wǎng)絡的網(wǎng)關的地址。
然后轉(zhuǎn)發(fā)這個包。
如果客戶端IP地址（ciaddr）是0，那么客戶端不知道自己的IP地址。
嘗試在我們的數(shù)據(jù)庫中查找客戶端的硬件地址(chaddr,hlen,htype)。
如果沒有匹配，丟棄這個包。否則我們現(xiàn)在對這個客戶端有一個IP地址；填入&＃039;yiaddr&＃039;（你
的IP地址）字段。
我們現(xiàn)在檢查引導文件名字段（文件）。如果客戶端不關注文件名或想要默認引導文件，
這個字段是空。
如果這個字段非空，可以將它和客戶端的IP地址做為數(shù)據(jù)庫的查詢關鍵字。
如果有默認的文件或通用文件（可能由客戶端地址做為索引）或一個匹配的指定的路徑
名稱，
然后在&＃039;file&＃039;字段中填入選擇的引導文件的指定的路徑名稱。
如果字段是非空并且沒有匹配，那么客戶端要一個我們沒有的文件，丟棄這個包，也許
其它BOOTP服務器有這個文件。
賣主指定的數(shù)據(jù)字段&＃039;vend&＃039;現(xiàn)在應該檢查了。如果提供一種可識別類型的數(shù)據(jù)，
應該進行客戶端指定的動作，并且回應要填入應答包中的&＃039;vend&＃039;數(shù)據(jù)字段。
例如，一個工作站客戶端可能提供一個驗證字，并從服務器接收一個訪問遠端文件的權(quán)
限，
或一套配置選項傳給馬上就要引導入的操作系統(tǒng)。
我的（服務器）IP地址填入&＃039;siaddr&＃039;字段。設置&＃039;op&＃039;字段為BOOTREPLY（引導應答）。
UDP目的端口設置成&＃039;BOOTP客戶端&＃039;。如果客戶端地址&＃039;ciaddr&＃039;非0，把包發(fā)送到那里；
否則如果網(wǎng)關地址&＃039;giaddr&＃039;非0，設置UDP目的端口為&＃039;BOOTP服務器&＃039;并把包發(fā)送到
&＃039;giaddr&＃039;。
否則客戶端在我們的一個網(wǎng)絡中但它還不知道自己的IP地址，使用在上面&＃039;蛋&＃039;章節(jié)中描述
的方法來傳送它到客戶端。
如果使用&＃039;蛋&＃039;并且我們在主機上有許多接口，使用&＃039;yiaddr&＃039;（你的IP地址）字段指出發(fā)送包
到哪個網(wǎng)絡（網(wǎng)絡/接口）。
[UDP校驗和]
6.4服務器/網(wǎng)關接收BOOTREPLY（引導應答）
[UDP校驗和]如果&＃039;yiaddr&＃039;(你的[客戶端的]IP地址)指向我們的一個網(wǎng)絡，使用上述&＃039;蛋&＃039;方
法來將它轉(zhuǎn)發(fā)到客戶端。
確認將它傳送到&＃039;BOOTP客戶端&＃039;UDP目的端口。
6.5客戶端接收
不要忘記為我自己的IP地址（如果我知道）處理ARP請求。[UDP校驗和]
客戶端應該丟棄以下進入的包：不是定位到引導端口的IP/UDP；不是BOOTREPLY（引
導應答）；
不匹配我的IP地址（如果我知道）或我的硬件地址；不匹配我的事務ID。
否則我們就收到一個成功的應答。如果我以前不知道的話，&＃039;yiaddr&＃039;包含我的IP地址。
&＃039;file&＃039;是TFTP&＃039;讀請求&＃039;的文件名。服務器地址在&＃039;siaddr&＃039;中。如果&＃039;giaddr&＃039;（網(wǎng)關地址）非0，
那么包應該先轉(zhuǎn)發(fā)到那里，然后到達服務器。
7 通過網(wǎng)關引導
這部分協(xié)議是可選的并要求許多網(wǎng)關和服務器配合的額外的代碼，但它允許跨越網(wǎng)關引導。
這主要在網(wǎng)關是無盤機器時有用。
帶盤網(wǎng)關（例如，一個做為網(wǎng)關的UNIX機器）可能運行它們自己的BOOTP/TFTP服務器。
偵聽BOOTREQUEST（引導請求）廣播的網(wǎng)關可能確定轉(zhuǎn)發(fā)還是適當?shù)卦購V播這些請求。
例如，做為配置表格的一部分，網(wǎng)關可以有一個接收任意BOOTREQUEST（引導請求）廣
播的其它網(wǎng)絡或主機的列表。
即使考慮有一個&＃039;hops&＃039;字段，簡單全部再廣播請求仍是一個差的方法，因為廣播循環(huán)幾乎肯
定會發(fā)生。
轉(zhuǎn)發(fā)可以立即開始，或等&＃039;secs&＃039;（客戶端嘗試的秒數(shù)）字段超過某個閥值。
如果一個網(wǎng)關確定轉(zhuǎn)發(fā)請求，它應該查看&＃039;giaddr&＃039;（網(wǎng)關IP地址）字段。
如果是0，它就在這個字段中加入自己的IP地址（在接收的網(wǎng)絡中）。
也可以使用&＃039;hops&＃039;字段來可選控制包可以轉(zhuǎn)發(fā)多遠。每次轉(zhuǎn)發(fā)應該增加跳數(shù)。
例如，如果跳數(shù)超過&＃039;3&＃039;，包應該被丟棄。
[UDP校驗和]
這里我們推薦在網(wǎng)關中增加這個特殊的轉(zhuǎn)發(fā)功能。
但不總是這樣子的。
在網(wǎng)上存在一些&＃039;BOOTP轉(zhuǎn)發(fā)代理&＃039;引導客戶端，這些代理可以適當?shù)剞D(zhuǎn)發(fā)。
這樣這些服務可以和網(wǎng)關在一起，也可以不在一起。
當轉(zhuǎn)發(fā)代理不和網(wǎng)關在一起時，代理可以通過在接收的引導請求中&＃039;giaddr&＃039;字段加上接口的廣
播地址節(jié)省一些工作。
這樣應答就可以使用普通的網(wǎng)關來轉(zhuǎn)發(fā)，而不包含轉(zhuǎn)發(fā)代理。
當然劣勢是你失去了使用&＃039;蛋&＃039;非廣播方式來發(fā)送應答的能力，導致在客戶端網(wǎng)上的每個主機
的額外的花費。


   

• 通信詞典解釋