BOOTP

BOOTP使用UDP報文傳輸，並使用保留埠號67（BOOTP伺服器）和68（BOOTP客戶端）工作。使用BOOTP協議的時候，一般包括Bootstrap Protocol Server（自舉協議服務端）和Bootstrap Protocol Client（自舉協議客戶端）兩部分。

BOOTP的一般工作流程就是BOOTP客戶端和BOOTP伺服器之間的交互，其流程如下：

1.由BOOTP啟動代碼來啟動BOOTP客戶端，這個時候BOOTP客戶端還沒有IP地址。

2.BOOTP客戶端使用廣播形式的IP地址255.255.255.255向網路中發出IP地址查詢要求。

3.運行BOOTP協議的伺服器接收到這個請求，會根據請求中提供的MAC地址找到BOOTP客戶端，併發送一個含有IP地址、伺服器IP地址、網關等信息的回應幀。

4.BOOTP客戶端會根據該回應幀來獲得自己的IP地址並通過專用文件伺服器（如TFTP伺服器）下載啟動鏡像文件，模擬成磁碟來完成啟動。

我們熟知的DHCP協議是從BOOTP的基礎上發展而來的，它們都是主機配置協議，都可以大大減少管理員的工作量。BOOTP可以看成是簡單版的DHCP，是對主機的靜態配置，而DHCP可以依據一些策略對主機進行動態配置。BOOTP用於無盤工作站的啟動和配置，而DHCP更適用於客戶端接入變化的網路，即客戶端接入時間、接入地點不固定。

本RFC描述一種IP/UDP引導協議(BOOTP)，允許一個無盤客戶端發現自己的IP地址，

伺服器主機的地址，和裝入一個指定名稱的文件到內存並且運行。引導操作有兩階段組成。

本RFC描述第一個階段：'分配地址和選擇引導文件'。

在獲得地址和文件名信息后，就進入引導的第二個階段：文件傳送。

文件傳送一般使用TFTP協議[9]，因為兩個階段均駐留在客戶端的PROM中。

但BOOTP也能夠與其它協議如SFTP或FTP一起工作。

我們建議客戶端的PROM軟體提供一種無須用戶交互的完整的引導方式。

這是一種無人值守的上電啟動方式。

必須提供一種機制來讓用戶手工提供地址和文件名信息旁路BOOTP協議直接進入文件傳送

階段。

如果提供非可變存儲，我們建議在那裡保存設置以旁路BOOTP協議直到這些設置導致文件

傳送階段失敗。

如果緩存的信息失敗，引導後退到第一階段並使用BOOTP。

1．使用了一個單獨的包交換（信息）。使用超時機制直到收到應答。

雙向使用相同的包欄位結構。使用（最大可能長度的）固定長度的欄位來簡化結構定義

和分析。

2．一個'opcode'欄位包含兩個值。客戶端廣播一個'引導請求(bootrequest)'包。

伺服器應答一個'引導應答(bootreply)'包。'bootrequest'包含客戶端的硬體地址，如果知道，

還包含它的IP地址。

3．請求可以包含客戶端指定的響應伺服器的名稱。

這樣客戶端可以強制從一個指定的主機引導。（如果一個相同的引導文件存在多種版本

或伺服器在一個遠距離的網路/域。）

客戶端不必處理名稱/域服務，這個功能推到了BOOTP伺服器。

4．請求可以包含'通用(generic)'引導文件名。例如'unix'或'ethertip'。但伺服器發送

引導應答時，它使用對應的引導文件的確切的路徑名稱來取代這個欄位。

伺服器查詢客戶端的地址和請求文件名相關的資料庫，以使用客戶端自定義的特定引導

文件確定這個文件名稱。

如果引導請求文件名是空字元串，伺服器返回一個帶有客戶端載入的默認文件的文件名

欄位。

5．客戶端不知道它們的IP地址的情況下，

伺服器必須有一個硬體地址和IP地址對應的資料庫。

這個客戶端IP地址被放在引導應答的（對應）欄位中。

6．某些網路拓樸（如斯坦福的網路）可能在一個物理網上沒有一個直接可以訪問的TFTP

伺服器

（例如在某些網上的所有的網關和主機都可能是無盤的）。

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地址，伺服器怎麼發送IP報文到客戶端。

無論何時一條引導應答被發送，發送設備執行下列操作：

（'ciaddr'欄位非零），

因為客戶端能夠回應ARPs[5]，那麼IP能夠正常發送。

（ciaddr是零），

客戶端就不能回應引導應答發送程序回的ARPs。這時有兩種選擇：

a.如果發送程序有必需的核心或驅動鉤子程序來人工建立ARP地址緩衝條目，

就可以使用'chaddr'和'yiaddr'欄位填入一個條目。當然，這個條目象正常ARP建立的

其它條目一樣有一個生命時間，

引導應答的發送程序就能夠簡單地發送引導應答到客戶端的IP地址了。UNIX(4.2

BSD)有這種功能。

b.如果發送程序缺少這些核心鉤子程序，就只能簡單發送引導應答到相應介面的廣播

地址。

這只是在前面情況外的額外的廣播。

客戶端PROM必須包含一個ARP的簡單實現，例如，地址緩衝能夠容納一個條目。

這將允許客戶端在知道IP地址和引導文件名后執行第二階段引導（TFTP）。

任何時候客戶端應該準備回應一個自己IP到硬體地址映射的ARP請求（如果知道）以接收

TFTP或BOOTP應答。

因為引導應答將包含伺服器/網關的硬體源地址（在硬體中封裝），客戶端可以

避免發送一條ARP請求來申請後續的TFTP階段使用的伺服器/網關IP地址。

但這應該只是一種特殊情況，因為上面描述的只有第二階段的引導仍然允許。

與RARP對照　提議客戶端使用一個早先的協議，反向地址解析協議(RARP)[1]來通過它的硬體地址確定自

己的IP地址。

但RARP的劣勢是它是一個硬體鏈路層的協議（不是基於IP/UDP）。

這意味著RARP只能在包含特殊的為訪問原始報文修改的核心和驅動的主機上實現。

因為存在不同組織維護的許多網路核心，一個不要求修改核心的引導協議是一個確定

的優勢。

BOOTP除了上述章節描述的有用的特性外，還提供硬體到IP地址的查詢功能。

在第一次建立包前，最好把整個包的緩衝區清零；

這將所有的欄位設置成默認狀態。任何客戶端建立包中的下列欄位。

IP目的地址被設置成255.255.255.255（廣播地址）或伺服器的IP地址（如果知道）。

IP源地址和'ciaddr'設置成客戶端IP地址（如果知道），或者0。UDP頭使用適當的長度設

置；

源埠='BOOTP客戶端'埠，目標埠='BOOTP伺服器'埠。

'op'設置成'1'，BOOTREQUEST（引導請求）。'htype'設置成在"Assigned

Numbers"RFCARP章節中分配的硬體地址類型。

'hlen'設置成硬體地址長度，例如，10M乙太網是'6'。

'xid'設置成一個'隨機'事務ID。'secs'設置成客戶端引導開始後過去的秒數。

這個讓伺服器知道客戶端已經試了多長時間了。

當數字變大，某些伺服器可能更多注意這個客戶端提供不同的服務。

如果客戶端缺少一個適當的時鐘，它可以使用循環定時器建立一個粗略的估計值。

或者它可以選擇簡單發送使用一個固定值如100秒的欄位。

如果客戶端知道IP地址，'ciaddr'（和IP源地址）設置成這個值。

'chaddr'使用客戶端硬體地址填寫。

如果客戶端希望限制從一個特定伺服器名引導，就可以在'sname'中放一個空結束的字元

串。

使用的名字應該是對應的主機的正當的名字或別名。

客戶端在填寫'file'文件名欄位是有許多選擇。

如果設置成空，意味著'我向使用默認的文件來引導我的機器'。一個空文件名也意味著

'我只對找到客戶端/伺服器/網關的IP地址感興趣，我不在乎文件名'。

這個欄位也可以是一個'通用'名字入'unix'或'gateway'；這意味著

'使用命名的程序配置來引導我的機器'。最後這個欄位可以是確切的目錄路徑名字。

'vend'欄位可以由客戶端填寫賣主的字元串或結構。例如可以填寫機器硬體類型或序列

號。

但BOOTP伺服器的操作應該不依賴與這些存在的信息。

如果使用了'vend'，推薦在'vend'中第一個項目為一個4位元組的'魔術字(magicnumber)'。

這讓伺服器確定在這個欄位中它看到什麼類型的信息。

數值可以由通常的'魔術字'過程分配，你挑一個，它就成為魔術字。

引導應答使用一個與引導請求不同的魔術字以允許客戶端按照應答信息進行特殊的動

作。

[UDP校驗和]

在一長段時間內沒有收到應答，客戶端應該重傳請求。

時間間隔必須仔細選擇不要引起網路風暴。

可以考慮一個包含100台機器的網路在電源故障后發生的情況。

簡單的每四秒重傳請求將淹沒網路。

一個可能的策略，你可能考慮指數級的補償，象乙太網在碰撞時那樣。

例如第一個包在0:00，第二個在:04，接著：08，接著：16，：32，：64。

你應該隨機化每個時間；這就象乙太網規格那樣以一個掩碼'與'一個隨機數進入第一次補

償。

在每次後續的補償中，掩碼增長一個比特。

這樣在每次補償中平均延遲加倍。

在'平均'補償到達60秒后，就不再增長了，但仍然隨機化。

在每次重傳前，客戶端應該修改'secs'欄位。[UDP校驗和]

[UDP校驗和]如果UDP目的埠不匹配'BOOTP伺服器'埠，丟棄這個包。

如果伺服器名字欄位(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（引導應答）。

UDP目的埠設置成'BOOTP客戶端'。如果客戶端地址'ciaddr'非0，把包發送到那裡；

否則如果網關地址'giaddr'非0，設置UDP目的埠為'BOOTP伺服器'並把包發送到

'giaddr'。

否則客戶端在我們的一個網路中但它還不知道自己的IP地址，使用在上面'蛋'章節中描述

的方法來傳送它到客戶端。

如果使用'蛋'並且我們在主機上有許多介面，使用'yiaddr'（你的IP地址）欄位指出發送包

到哪個網路（網路/介面）。

[UDP校驗和]

[UDP校驗和]如果'yiaddr'(你的[客戶端的]IP地址)指向我們的一個網路，使用上述'蛋'方

法來將它轉發到客戶端。

確認將它傳送到'BOOTP客戶端'UDP目的埠。

不要忘記為我自己的IP地址（如果我知道）處理ARP請求。[UDP校驗和]

客戶端應該丟棄以下進入的包：不是定位到引導埠的IP/UDP；不是BOOTREPLY（引

導應答）；

不匹配我的IP地址（如果我知道）或我的硬體地址；不匹配我的事務ID。

否則我們就收到一個成功的應答。如果我以前不知道的話，'yiaddr'包含我的IP地址。

'file'是TFTP'讀請求'的文件名。伺服器地址在'siaddr'中。如果'giaddr'（網關地址）非0，

那麼包應該先轉發到那裡，然後到達伺服器。

這部分協議是可選的並要求許多網關和伺服器配合的額外的代碼，但它允許跨越網關引導。

這主要在網關是無盤機器時有用。

帶盤網關（例如，一個做為網關的UNIX機器）可能運行它們自己的BOOTP/TFTP伺服器。

偵聽BOOTREQUEST（引導請求）廣播的網關可能確定轉發還是適當地再廣播這些請求。

例如，做為配置表格的一部分，網關可以有一個接收任意BOOTREQUEST（引導請求）廣

播的其它網路或主機的列表。

即使考慮有一個'hops'欄位，簡單全部再廣播請求仍是一個差的方法，因為廣播循環幾乎肯

定會發生。

轉發可以立即開始，或等'secs'（客戶端嘗試的秒數）欄位超過某個閥值。

如果一個網關確定轉發請求，它應該查看'giaddr'（網關IP地址）欄位。

如果是0，它就在這個欄位中加入自己的IP地址（在接收的網路中）。

也可以使用'hops'欄位來可選控制包可以轉發多遠。每次轉發應該增加跳數。

例如，如果跳數超過'3'，包應該被丟棄。

[UDP校驗和]

這裡我們推薦在網關中增加這個特殊的轉發功能。

但不總是這樣子的。

在網上存在一些'BOOTP轉發代理'引導客戶端，這些代理可以適當地轉發。

這樣這些服務可以和網關在一起，也可以不在一起。

當轉發代理不和網關在一起時，代理可以通過在接收的引導請求中'giaddr'欄位加上介面的廣

播地址節省一些工作。

這樣應答就可以使用普通的網關來轉發，而不包含轉發代理。

當然劣勢是你失去了使用'蛋'非廣播方式來發送應答的能力，導致在客戶端網上的每個主機

的額外的花費。