Toad的博客

1 概述

本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允许客户端通过使用相邻的网关从几跳外的服务器上引导。请看下面’通过网关引导’的章节。

这部分协议不需求客户端部分做特定的动作。

实现是可选的，网关和服务器需要一些额外的代码。

点击下载：[PDF]RFC951_引导协议(BOOTP)_中文版