組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：金濤（piex  albertxu@bigfoot.com）
譯文發布時間：2001-07-05
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須保留本
文檔的翻譯及版權信息。


Network Working Group                         Bill Croft (Stanford University)
Request for Comments: 951                     John Gilmore (Sun Microsystems)
                                                          September 1985

引導協議(BOOTP)
(RFC951-BOOTSTRAP PROTOCOL (BOOTP))


本備忘錄的狀態

   本RFC文檔向ARPA-Internet社區提供一個被提議的協議，需要進一步進行討論和建議以得
到改進。
   本文檔無發布限制。
目錄
1	概述	2
2	包格式	3
3	雞和蛋的問題	6
4	ARP在客戶端使用	7
5	與RARP對照	7
6	包處理	7
6.1   客戶端傳送	7
6.2   客戶端重傳策略	9
6.3  服務器接收BOOTREQUEST（引導請求）	9
6.4  服務器/網關接收BOOTREPLY（引導應答）	11
6.5   客戶端接收	11
7	通過網關引導	11
8	樣例BOOTP服務器數據庫	12
9	致謝	14
10	參考文獻	14




1	概述
	
	   本RFC描述一種IP/UDP引導協議(BOOTP)，允許一個無盤客戶端發現自己的IP地址，
	   服務器主機的地址，和裝入一個指定名稱的文件到內存并且運行。引導操作有兩階段組成。
	   本RFC描述第一個階段：'分配地址和選擇引導文件'。
	   在獲得地址和文件名信息后，就進入引導的第二個階段：文件傳送。
	   文件傳送一般使用TFTP協議[9]，因為兩個階段均駐留在客戶端的PROM中。
	   但BOOTP也能夠與其它協議如SFTP或FTP一起工作。
	
	   我們建議客戶端的PROM軟件提供一種無須用戶交互的完整的引導方式。
	   這是一種無人值守的上電啟動方式。
	   必須提供一種機制來讓用戶手工提供地址和文件名信息旁路BOOTP協議直接進入文件傳送
階段。
	   如果提供非可變存儲，我們建議在那里保存設置以旁路BOOTP協議直到這些設置導致文件
傳送階段失敗。
	   如果緩存的信息失敗，引導后退到第一階段并使用BOOTP。
	   
	   協議的要點：
	
	      1.使用了一個單獨的包交換（信息）。使用超時機制直到收到應答。
	      雙向使用相同的包字段結構。使用（最大可能長度的）固定長度的字段來簡化結構定義
和分析。
	      
	      2.一個'opcode'字段包含兩個值?？蛻舳藦V播一個'引導請求(bootrequest)'包。
	      服務器應答一個'引導應答(bootreply)'包。'bootrequest'包含客戶端的硬件地址，如果知道，
還包含它的IP地址。
	
	      3.請求可以包含客戶端指定的響應服務器的名稱。
	      這樣客戶端可以強制從一個指定的主機引導。（如果一個相同的引導文件存在多種版本
或服務器在一個遠距離的網絡/域。）
	      客戶端不必處理名稱/域服務，這個功能推到了BOOTP服務器。
	
	      4.請求可以包含'通用(generic)'引導文件名。例如'unix'或'ethertip'。但服務器發送
	      引導應答時，它使用對應的引導文件的確切的路徑名稱來取代這個字段。
	      服務器查詢客戶端的地址和請求文件名相關的數據庫，以使用客戶端自定義的特定引導
文件確定這個文件名稱。
	      
	      如果引導請求文件名是空字符串，服務器返回一個帶有客戶端加載的默認文件的文件名
字段。
	
	      5.客戶端不知道它們的IP地址的情況下，
	      服務器必須有一個硬件地址和IP地址對應的數據庫。
	      這個客戶端IP地址被放在引導應答的（對應）字段中。
	
	      6.某些網絡拓樸（如斯坦福的網絡）可能在一個物理網上沒有一個直接可以訪問的TFTP
服務器
	      （例如在某些網上的所有的網關和主機都可能是無盤的）。
	      BOOTP允許客戶端通過使用相鄰的網關從幾跳外的服務器上引導。請看下面'通過網關
引導'的章節。
	      這部分協議不需求客戶端部分做特定的動作。
	      實現是可選的，網關和服務器需要一些額外的代碼。
	
2	包格式
	
	   除非另外指出，所有顯示的數字都是十進制的。
	   簡化起見，假設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未使用
	
	         ciaddr  4       client IP address;客戶端IP地址，
	                         filled in by client in bootrequest if known.如果客戶端知道就在引導
請求中填入
	
	         yiaddr  4       'your' (client) IP address;'你的'（客戶端）IP地址
	                         filled by server if client doesn'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,網關IP地址
	                         used in optional cross-gateway booting.在跨越網關引導中可以選擇
使用
	
	         chaddr  16      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.
	
	
3	雞和蛋的問題
	
	   如果客戶端不知道自己IP地址，服務器怎么發送IP報文到客戶端。
	   無論何時一條引導應答被發送，發送設備執行下列操作：
	
	      1.如果客戶端知道自己的IP地址（'ciaddr'字段非零），
	      因為客戶端能夠回應ARPs [5]，那么IP能夠正常發送。
	
	      2.如果客戶端還不知道自己的IP地址（ciaddr是零），
	      客戶端就不能回應引導應答發送程序回的ARPs。這時有兩種選擇：
	
	         a.如果發送程序有必需的核心或驅動鉤子程序來人工建立ARP地址緩沖條目，
	
	         就可以使用'chaddr'和'yiaddr'字段填入一個條目。當然，這個條目象正常ARP建立的
其它條目一樣有一個生命時間，
	         引導應答的發送程序就能夠簡單地發送引導應答到客戶端的IP地址了。UNIX (4.2 
BSD)有這種功能。
	
	         b.如果發送程序缺少這些核心鉤子程序，就只能簡單發送引導應答到相應接口的廣播
地址。
	         這只是在前面情況外的額外的廣播。
	
4	ARP在客戶端使用
	
	   客戶端PROM必須包含一個ARP的簡單實現，例如，地址緩沖能夠容納一個條目。
	   這將允許客戶端在知道IP地址和引導文件名后執行第二階段引導（TFTP）。
	
	   任何時候客戶端應該準備回應一個自己IP到硬件地址映射的ARP請求（如果知道）以接收
TFTP或BOOTP應答。
	
	   因為引導應答將包含服務器/網關的硬件源地址（在硬件中封裝），客戶端可以
	   避免發送一條ARP請求來申請后續的TFTP階段使用的服務器/網關IP地址。
	   但這應該只是一種特殊情況，因為上面描述的只有第二階段的引導仍然允許。
	
5	與RARP對照
	
	   提議客戶端使用一個早先的協議，反向地址解析協議(RARP) [1]來通過它的硬件地址確定自
己的IP地址。
	   但RARP的劣勢是它是一個硬件鏈路層的協議（不是基于IP/UDP）。
	   這意味著RARP只能在包含特殊的為訪問原始報文修改的核心和驅動的主機上實現。
	   因為現在存在不同組織維護的許多網絡核心，一個不要求修改核心的引導協議是一個確定
的優勢。
	
	   BOOTP除了上述章節描述的有用的特性外，還提供硬件到IP地址的查詢功能。
	
6	包處理
6.1   客戶端傳送
	
	      在第一次建立包前，最好把整個包的緩沖區清零；
	      這將所有的字段設置成默認狀態。任何客戶端建立包中的下列字段。
	
	      IP目的地址被設置成255.255.255.255（廣播地址）或服務器的IP地址（如果知道）。
	      IP源地址和'ciaddr'設置成客戶端IP地址（如果知道），或者0。UDP頭使用適當的長度設
置；
	      源端口='BOOTP客戶端'端口，目標端口='BOOTP服務器'端口。