'op'設置成'1'，BOOTREQUEST（引導請求）。'htype'設置成在"Assigned
	      Numbers" RFC ARP章節中分配的硬件地址類型。
	      'hlen'設置成硬件地址長度，例如，10M以太網是'6'。
	
	      'xid'設置成一個'隨機'事務ID。'secs'設置成客戶端引導開始后過去的秒數。
	      這個讓服務器知道客戶端已經試了多長時間了。
	      當數字變大，某些服務器可能更多注意這個客戶端提供不同的服務。
	      如果客戶端缺少一個適當的時鐘，它可以使用循環定時器建立一個粗略的估計值。
	      或者它可以選擇簡單發送使用一個固定值如100秒的字段。
	
	      如果客戶端知道IP地址，'ciaddr'（和IP源地址）設置成這個值。
	      'chaddr'使用客戶端硬件地址填寫。
	
	      如果客戶端希望限制從一個特定服務器名引導，就可以在'sname'中放一個空結束的字符
串。
	      使用的名字應該是對應的主機的正當的名字或別名。
	
	      客戶端在填寫'file'文件名字段是有許多選擇。
	      如果設置成空，意味著'我向使用默認的文件來引導我的機器'。一個空文件名也意味著
	      '我只對找到客戶端/服務器/網關的IP地址感興趣，我不在乎文件名'。
	
	      這個字段也可以是一個'通用'名字入'unix'或'gateway'；這意味著
	
	      '使用命名的程序配置來引導我的機器'。最后這個字段可以是確切的目錄路徑名字。
	
	      'vend'字段可以由客戶端填寫賣主的字符串或結構。例如可以填寫機器硬件類型或序列
號。
	      但BOOTP服務器的操作應該不依賴與這些存在的信息。
	
	      如果使用了'vend'，推薦在'vend'中第一個項目為一個4字節的'魔術字(magic number)'。
	      這讓服務器確定在這個字段中它看到什么類型的信息。
	      數值可以由通常的'魔術字'過程分配，你挑一個，它就成為魔術字。
	      引導應答使用一個與引導請求不同的魔術字以允許客戶端按照應答信息進行特殊的動
作。
	
	      [UDP校驗和]
	
6.2   客戶端重傳策略
	
	      在一長段時間內沒有收到應答，客戶端應該重傳請求。
	      時間間隔必須仔細選擇不要引起網絡風暴。
	      可以考慮一個包含100臺機器的網絡在電源故障后發生的情況。
	      簡單的每四秒重傳請求將淹沒網絡。
	
	      一個可能的策略，你可能考慮指數級的補償，象以太網在碰撞時那樣。
	      例如第一個包在0:00，第二個在:04，接著:08，接著:16，:32，:64。
	      你應該隨機化每個時間；這就象以太網規格那樣以一個掩碼'與'一個隨機數進入第一次補
償。
	      在每次后續的補償中，掩碼增長一個比特。
	      這樣在每次補償中平均延遲加倍。
	
	      在'平均'補償到達60秒后，就不再增長了，但仍然隨機化。
	
	      在每次重傳前，客戶端應該修改'secs'字段。[UDP校驗和]
	
6.3  服務器接收BOOTREQUEST（引導請求）
	
	      [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校驗和]
	
6.4  服務器/網關接收BOOTREPLY（引導應答）
	
	      [UDP校驗和] 如果'yiaddr' (你的[客戶端的]IP地址)指向我們的一個網絡，使用上述'蛋'方
法來將它轉發到客戶端。
	      確認將它傳送到'BOOTP客戶端'UDP目的端口。
	
6.5   客戶端接收
	
	      不要忘記為我自己的IP地址（如果我知道）處理ARP請求。[UDP校驗和]
	      客戶端應該丟棄以下進入的包：不是定位到引導端口的IP/UDP；不是BOOTREPLY（引
導應答）；
	      不匹配我的IP地址（如果我知道）或我的硬件地址；不匹配我的事務ID。
	      否則我們就收到一個成功的應答。如果我以前不知道的話，'yiaddr'包含我的IP地址。
	      'file'是TFTP'讀請求'的文件名。服務器地址在'siaddr'中。如果'giaddr'（網關地址）非0，
	      那么包應該先轉發到那里，然后到達服務器。
	
7	 通過網關引導
	
	   這部分協議是可選的并要求許多網關和服務器配合的額外的代碼，但它允許跨越網關引導。
	   這主要在網關是無盤機器時有用。
	   帶盤網關（例如，一個做為網關的UNIX機器）可能運行它們自己的BOOTP/TFTP服務器。
	
	   偵聽BOOTREQUEST（引導請求）廣播的網關可能確定轉發還是適當地再廣播這些請求。
	
	   例如，做為配置表格的一部分，網關可以有一個接收任意BOOTREQUEST（引導請求）廣
播的其它網絡或主機的列表。
	   即使考慮有一個'hops'字段，簡單全部再廣播請求仍是一個差的方法，因為廣播循環幾乎肯
定會發生。
	
	   轉發可以立即開始，或等'secs'（客戶端嘗試的秒數）字段超過某個閥值。
	
	   如果一個網關確定轉發請求，它應該查看'giaddr' （網關IP地址）字段。
	   如果是0，它就在這個字段中加入自己的IP地址（在接收的網絡中）。
	   也可以使用'hops'字段來可選控制包可以轉發多遠。每次轉發應該增加跳數。
	   例如，如果跳數超過'3'，包應該被丟棄。
	   [UDP校驗和]
	
	   這里我們推薦在網關中增加這個特殊的轉發功能。
	   但不總是這樣子的。
	   在網上存在一些'BOOTP轉發代理'引導客戶端，這些代理可以適當地轉發。
	   這樣這些服務可以和網關在一起，也可以不在一起。
	
	   當轉發代理不和網關在一起時，代理可以通過在接收的引導請求中'giaddr'字段加上接口的廣
播地址節省一些工作。
	   這樣應答就可以使用普通的網關來轉發，而不包含轉發代理。
	   當然劣勢是你失去了使用'蛋'非廣播方式來發送應答的能力，導致在客戶端網上的每個主機
的額外的花費。
	
8	 樣例BOOTP服務器數據庫
	
	   做為一個建議，我們提供一個BOOTP服務器查詢可以使用的樣例文本文件數據庫。
	   數據庫有兩個節，使用第一列使用一個百分符的行做為定界符。
	   第一個節包含一個'默認目錄'，和從通用名稱到目錄/路徑的映射。
	   這個節中第一個通用名稱是當引用請求包含空'file'字符串是你使用的'默認文件'。
	
	   第二節映射硬件地址類型/地址到IP地址。可選的，你可以使用一個特定IP地址的通用名稱
來忽略默認通用名稱。
	   一個'后綴'項目也是可選的；如果提供，可以訪問任意客戶端特定的通用名稱對應的'路徑名
稱'加上'后綴'。
	
	   如果那個文件沒有找到，就嘗試簡單的'路徑名稱'。
	   這個'后綴'選項允許輕而易舉建立整套用戶通用（配置）。
	   
	   下面顯示通用格式；一個或多個空格或TAB來定界字段；后面的空字段被省略；空行和以'#'
開始的行忽略。
	
	      # comment line
	
	      homedirectory
	      genericname1    pathname1
	      genericname2    pathname2
	      ...
	
	      % end of generic names, start of address mappings
	
	      hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
	      hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
	      ...
	
	   這是一個特定的樣例。注意'硬件類型'數值同'Assigned Numbers' RFC中ARP章節。
	   '硬件類型'和'IP地址'數值是十進制；'硬件地址'是十六進制的。
	
	      # last updated by smith
	
	      /usr/boot
	      vmunix          vmunix
	      tip             ethertip
	      watch           /usr/diag/etherwatch
	      gate            gate.
	
	      % end of generic names, start of address mappings
	
	      hamilton        1 02.60.8c.06.34.98     36.19.0.5
	      burr            1 02.60.8c.34.11.78     36.44.0.12
	      101-gateway     1 02.60.8c.23.ab.35     36.44.0.32      gate 101
	      mjh-gateway     1 02.60.8c.12.32.bc     36.42.0.64      gate mjh
	      welch-tipa      1 02.60.8c.22.65.32     36.47.0.14      tip
	      welch-tipb      1 02.60.8c.12.15.c8     36.46.0.12      tip
	
	   在上述樣例中，如果'mjh-gateway'是一個默認的引導程序，它將得到文件'/usr/boot/gate.mjh'。
	
9	 致謝
	
	   Ross Finlayson等早先提出了兩個使用討論RARP[1]的TFTP引導的RFC。
	   
	   我們感謝Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, 和David Plummer的前期工作和
注解。
	
10	參考文獻
	
	   1.  Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer.  A
	       Reverse Address Resolution Protocol.  RFC 903, NIC, June, 1984.
	
	   2.  Ross Finlayson.  Bootstrap Loading using TFTP.  RFC 906, NIC,
	       June, 1984.
	
	   3.  Mark Lottor.  Simple File Transfer Protocol.  RFC 913, NIC,
	       September, 1984.
	
	   4.  Jeffrey Mogul.  Broadcasting Internet Packets.  RFC 919, NIC,
	       October, 1984.
	
	   5.  David Plummer.  An Ethernet Address Resolution Protocol.  RFC
	       826, NIC, September, 1982.
	
	   6.  Jon Postel.  File Transfer Protocol.  RFC 765, NIC, June, 1980.
	
	   7.  Jon Postel.  User Datagram Protocol.  RFC 768, NIC, August, 1980.
	
	   8.  Jon Postel.  Internet Protocol.  RFC 791, NIC, September, 1981.
	
	   9.  K. R. Sollins, Noel Chiappa.  The TFTP Protocol.  RFC 783, NIC,
	       June, 1981.
	
	
RFC951——RFC951-BOOTSTRAP PROTOCOL (BOOTP)                    引導協議(BOOTP)


1
RFC文檔中文翻譯計劃