第16章 BOOTP：引导程序协议
16.1 引言
在第5章我们介绍了一个无盘系统，它在不知道自身 IP地址的情况下，在进行系统引导时 能够通过 RARP来获取它的 IP地址。然而使用 RARP有两个问题：（1）IP地址是返回的唯一结 果；（ 2）既然 RARP使用链路层广播， RARP 请求就不会被路由器转发（迫使每个实际网络 设置一个 RARP 服务器）。本章将介绍一种用于无盘系统进行系统引导的替代方法，又称为引 导程序协议，或 BOOTP。
B O O T P使用 U D P ，且通常需与 T F T P （参见第 1 5 章）协同工作。 RFC 951 [Croft and
Gilmore 1985]是BOOTP的正式规范， RFC 1542 [Wimer 1993] 则对它作了说明。
16.2 BOOTP 的分组格式
BOOTP 请求和应答均被封装在 UDP数据报中，如图 16-1所示。
IP数据报
UDP数据报
IP首部 UDP首部 BOOTP请求/应答
20字节 8字节 300字节
图16-1 BOOTP 请求和应答封装在一个UDP数据报内
图16-2显示了长度为 300字节的 BOOTP请求和应答的格式。
“操作码”字段为 1表示请求，为 2表示应答。硬件类型字段为 1表示10 Mb/s 的以太网，这 和ARP请求或应答（图 4-3）中同名字段表示的含义相同。类似地，对于以太网，硬件地址长 度字段为 6字节。
“跳数”字段由客户设置为 0，但也能被一个代理服务器设置（参见 16.5节）。 “事务标识”字段是一个由客户设置并由服务器返回的 32 bit 整数。客户用它对请求和应
答进行匹配。对每个请求，客户应该将该字段设置为一个随机数。 客户开始进行引导时，将“秒数”字段设置为一个时间值。服务器能够看到这个时间值，
备用服务器在等待时间超过这个时间值后才会响应客户的请求，这意味着主服务器没有启动。 如果该客户已经知道自身的 IP地址，它将写入“客户 IP地址”字段。否则，它将该字段 设置为 0。对于后面这种情况，服务器用该客户的 IP地址写入“你的 IP地址”字段。“服务器 IP地址”字段则由服务器填写。如果使用了某个代理服务器（见 16.5节），则该代理服务器就
填写“网关 IP地址”字段。 客户必须设置它的“客户硬件地址”字段。尽管这个值与以太网数据帧头中的值相同，
UDP数据报中也设置这个字段，但任何接收这个数据报的用户进程能很容易地获得它（例如
一个BOOTP服务器）。一个进程通过查看UDP数据报来确定以太网帧首部中的该字段通常是很困难的（或者说是不可能的）。
操作码
(1=请求,2=应答)
硬件类型
(1=以太网)
硬件地址长度
(以太网为6) 跳数
事务标识
秒数 未使用
客户IP地址
你的IP地址
服务器IP地址
网关IP地址
300字节
客户主机硬件地址(16字节)
服务器主机名(64字节)
引导文件名(128字节)
特定厂商信息(64字节)
图16-2 BOOTP请求和应答的格式
“服务器主机名”字段是一个空值终止串，由服务器填写。服务器还将在“引导文件名字 段”填入包括用于系统引导的文件名及其所在位置的路径全名。
“特定厂商区域”字段用于对 BOOTP进行不同的扩展。 16.6节将介绍这些扩展中的一些。 当一个客户使用BOOTP（操作码为1）进行系统引导时，引导请求通常是采用链路层广
播， I P 首部中的目的 I P 地址为 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 （受限的广播， 1 2 . 2 节）。源 I P 地址通常是
0.0.0.0，因为此时客户还不知道它本身的 IP地址。回顾图 3-9，在系统进行自引导时， 0.0.0.0
是一个有效的 IP地址。
端口号
BOOTP有两个熟知端口：BOOTP服务器为 67，BOOTP客户为68。这意味着BOOTP客 户不会选择未用的临时端口，而只用端口68。选择两个端口而不是仅选择一个端口为 BOOTP 服务器用的原因是：服务器的应答可以进行广播（但通常是不用广播的）。
如果服务器的应答是通过广播传送的，同时客户又选择未用的临时端口，那么这些广播
也能被其他的主机中碰巧使用相同临时端口的应用进程接收到。因此，采用随机端口（即临时端口）对广播来说是一个不好的选择。
如果客户也使用服务器的知名端口（ 67）作为它的端口，那么网络内的所有服务器会被唤醒来查看每个广播应答（如果所有的服务器都被唤醒，它们将检查操作码，如果是一个应 答而不是请求，就不作处理）。因此可以让所有的客户使用与服务器知名端口不同的同一知名端口。
如果多个客户同时进行系统引导，并且服务器广播所有应答，这样每个客户都会收到其他客户的应答。客户可以通过 BOOTP首部中的事务标识字段来确认应答是否与请求匹配，或者可以通过检查返回的客户硬件地址加以区分。
16.3 一个例子
让我们看一个用BOOTP引导一个 X终端的例子。图16-3显示了tcpdump的输出结果（例 中客户名为 proteus，服务器名为 mercury。这个 tcpdump的输出是在不同的网络上获得 的，这个应用程序是其他例子中一直使用的）。
这里删除了许多行
图16-3 用BOOTP引导一个X终端的例子
在第1行中，我们看到客户请求来自 0.0.0.0.68，发送目的站是255.255.255.255.67。该客 户已经填写的字段是秒数和自身的以太网地址。我们看到客户通常将秒数设置为 1 0 0 。 tcpdump 没有显示跳数和事务标识，因为它们均为 0( 事务标识为0表示该客户忽略这个字段，
因为如果打算对返回响应进行验证，它将把这个字段设置为一个随机数值)。 第2行是服务器返回的应答。由服务器填写的字段是该客户的IP地址（tcpdump显示为名
字proteus）、服务器的 IP地址（显示为名字mercury）、网关的 IP地址（显示为名字
mercury）和引导文件名。 在收到BOOTP应答后，该客户立即发送一个ARP请求来了解网络中其他主机是否有 IP地址。
跟在who-has后的名字 proteus对应目的 IP地址（图 4-3），发送者的 IP地址被设置为0.0.0.0。 它在0.5秒后再发一个相同的ARP请求，之后再过0.5秒又发一个。在第3个ARP请求（第5行）中， 它将发送者的IP地址改变为它自己的IP地址。这是一个没有意义的 ARP请求（见4.7节）。
第6行显示该客户在等待另一个 0.5秒后，广播另一个 BOOTP请求。这个请求与第1行的唯 一不同是此时客户将它的 IP地址写入 IP首部中。它收到来自同一个服务器的相同应答（第7行）。该客户在等待 2秒后，又广播一个BOOTP请求（第8行），同样收到来自同一服务器的相同应 答。
该客户等待2秒后，向它的服务器mercury发送一个 ARP请求（第 10行）。收到这个 ARP 应答后，它立即发送一个TFTP读请求，请求读取它的引导文件（第12行）。文件传送过程包 括2464个TFTP数据分组和确认，传送的数据量为 512×2463+ 224 = 1 261 280 字节。这将操 作系统调入 X终端。我们已在图16-3中删除了大多数TFTP行。
当和图 15-2比较 TFTP的数据交换过程时，要注意的是这儿的客户在整个传输过程中使用TFTP的知名端口（69）。既然通信双方中的一方使用了端口 69，tcpdump就知道这些分组是 TFTP报文，因此它能用 TFTP协议来解释每个分组。这就是为什么图16-3能指明哪些包含有数 据，哪些包含有确认，以及每个分组的块编号。在图15-2中我们并不能获得这些额外的信息，因为通信双方均没有使用 TFTP的知名端口进行数据传送。由于TFTP服务器作为一个多用户
系统，且使用TFTP的知名端口，因此通常TFTP客户不能使用那个端口。但这里的系统处于正被引导的过程中，无法提供一个TFTP服务器，因此允许该客户在传输期间使用 TFTP的知名端口。这也暗示在 mercury上的TFTP服务器并不关心客户的端口号是什么—它只将数据传送 到客户的端口上，而不管发生了什么。
从图16-3可以看出在 9秒内共传送了1 261 280 字节。数据速率大约为140 000 bps。这比大 多数以 FTP文件传送形式访问一个以太网要慢，但对于一个简单的停止等待协议如 TFTP来说 已经很好了。
X终端系统引导后，还需使用 TFTP传送终端的字体文件、某些 DNS名字服务器查询，然 后进行X协议的初始化。图16-3中的所有步骤大概需要15秒钟，其余的步骤需要6秒钟，这样 无盘X终端系统引导的总时间是21秒。
16.4 BOOTP服务器的设计
BOOTP客户通常固化在无盘系统只读存储器中，因此了解 BOOTP 服务器的实现将更有 意义。
首先，BOOTP服务器将从它的熟知端口（67）读取UDP数据报。这没有特别的地方。它 不同于RARP服务器 （5.4节），它必须读取类型字段为“ RARP请求”的以太网帧。BOOTP 协议通过将客户的硬件地址放入BOOTP分组中，使得服务器很容易获取客户的硬件地址 (图
16-2)。
这里出现了一个有趣的问题： TFTP 服务器如何能将一个响应直接送回 BOOTP 客户？这个响应是一个 UDP数据报，而服务器知道该客户的IP地址（可能通过读取服务器上的配置文件）。但如果这个客户向那个 IP地址发送一个UDP数据报（正常情况下会处理UDP的输出）， BOOTP 服务器的主机就可能向那个IP地址发送一个ARP请求。但这个客户不能响应这个ARP 请求，因为它还不知道它自己的IP地址！（这就是在RFC951中被称作“鸡和蛋”的问题。）
有两种解决办法：第一种，通常被 Unix 服务器采用，是服务器发一个 ioctl(2)请求给内核， 为该客户在ARP高速缓存中设置一个条目（这就是命令arp-s所做的工作，见 4.8节）。服务 器能一直这么做直到它知道客户的硬件地址和 I P地址。这意味着当服务器发送 UD P 数据报
（即BOOTP应答）时，服务器的 ARP将在ARP高速缓存中找到该客户的IP地址。 另一种可选的解决办法是服务器广播这个 BOOTP应答而不直接将应答发回该客户。既然
通常期望网络广播越少越好，因此这种解决方案应该只在服务器无法在它的 ARP 高速缓存设 置一个条目的情况下使用。通常只有拥有超级用户权限才能在 ARP高速缓存设置一个条目， 如果没有这种权限就只能广播BOOTP应答。
16.5 BOOTP穿越路由器
我们在5.4节中提到RARP的一个缺点就是它使用链路层广播，这种广播通常不会由路由器转发。这就需要在每个物理网络内设置一个 RARP 服务器。如果路由器支持BOOTP协议， 那么BOOTP能够由路由器转发（绝大多数路由器厂商的产品都支持这个功能）。
这个功能主要用于无盘路由器，因为如果在磁盘的多用户系统被用作路由器，它就能够 自己运行BOOTP 服务器。此外，常用的UnixBOOTP 服务器（附录 F ）支持这种中继模式
（relay mode）。但如果在这个物理网络内运行一个 BOOTP 服务器，通常没有必要将 BOOTP请求转发到在另外网络中的另一个服务器。
研究一下当路由器（也称作“BOOTP 中继代理”）在服务器的熟知端口（67）接收到 BOOTP请求时将会发生什么。当收到一个BOOTP请求时，中继代理将它的IP地址填入收到 BOOTP请求中的“网关IP地址字段”，然后将该请求发送到真正的 BOOTP服务器（由中继代 理填入网关字段的地址是收到的BOOTP请求接口的IP地址）。该代理中继还将跳数字段值加 1
（这是为防止请求被无限地在网络内转发。RFC951认为如果跳数值到达 3就可以丢弃该请求）。 既然发出的请求是一个单播的数据报（与发起的客户的请求是广播的相反），它能按照一定的路由通过其他的路由器到达真正的 BOOTP服务器。真正的 BOOTP服务器收到这个请求后，产 生BOOTP应答，并将它发回中继代理，而不是请求的客户。既然请求网关字段不为零，真正 的BOOTP服务器知道这个请求是经过转发的。中继代理收到应答后将它发给请求的客户。
16.6 特定厂商信息
在图16 - 2 中我们看到了64 字节的“特定厂商区域”。RFC 1533 [Alexander and Droms
1993] 定义了这个区域的格式。这个区域含有服务器返回客户的可选信息。 如果有信息要提供，这个区域的前4个字节被设置为IP地址99.130.83.99。这可称作魔术
甜饼(magic cookie)，表示该区域内包含信息。 这个区域的其余部分是一个条目表。每个条目的开始是1字节标志字段。其中的两个条目
仅有标志字段：标志为 0的条目作为填充字节（为使后面的条目有更好的字节边界），标志为
255的条目表示结尾条目。第一个结尾条目后剩余的字节都应设置为这个数值（255）。 除了这两个 1字节的条目，其他的条目还包含一个单字节的长度字段，后面是相应的信息。
图16-4显示了厂商说明区域中一些条目的格式。
填充：
1字节
子网掩码：
tag=1
len=4
子网掩码
1字节 1字节 4字节
时间偏移：
tag=2
1字节
len=4
1字节
时间
4字节
网关：
tag=3
1字节
len=N
1字节
首选网关的IP地址
4字节
N字节
网关IP地址
4字节
14个其他条目：tag=4~17
结尾：
1字节
图16-4 厂商说明区域中一些条目的格式
子网掩码条目和时间值条目都是定长条目，因为它们的值总是占4个字节。时间偏移值是 从1900年1月1日0时以来的秒数（UTC）。
网关条目是变长条目。长度通常是 4 的倍数，这个值是一个或多个供客户使用的网关（路 由器）的 IP地址。返回的第一个必须是首选的网关。
RFC 1533 还定义了其他14个条目。其中最重要的可能是DNS名字服务器的IP地址条目， 条目的志为6。其他的条目包括打印服务器、时间服务器等的IP地址。详细情况可参考RFC文 档。
回到在图 16-3中的例子，我们从未看到客户广播一个ICMP地址掩码请求（6.3节）来获取 它的子网掩码。尽管 tcpdump不能显示出来，但我们可认为客户所在网络的子网掩码在返回的BOOTP应答的厂商说明区域内。
Host Requirements RFC 文档推荐一个系统使用 BOOTP来获悉它的子网掩码，而不是采用
ICMP。
厂商说明区域的大小被限制为 64字节。这对某些应用是个约束。一个新的称为动态主机 配置协议 DHCP（Dynamic Host Configuration Protocol）已经出现，但它不是替代 BOOTP的。DHCP将这个区域的长度扩展到312字节，它在 RFC 1541 [Droms 1993] 中定义。
16.7 小结
BOOTP使用UDP，它为引导无盘系统获得它的IP地址提供了除RARP外的另外一种选择。
BOOTP还能返回其他的信息，如路由器的IP地址、客户的子网掩码和名字服务器的IP地址。 既然 BOOTP用于系统引导过程，一个无盘系统需要下列协议才能在只读存储器中完成：
BOOTP、TFTP、UDP、IP和一个局域网的驱动程序。
BOOTP服务器比 RARP 服务器更易于实现，因为 BOOTP请求和应答是在UDP数据报中， 而不是特殊的数据链路层帧。一个路由器还能作为真正BOOTP服务器的代理，向位于不同网 络的真正 BOOTP服务器转发客户的BOOTP请求。
习题
16.1 我们说BOOTP优于RARP的一个方面是BOOTP能穿越路由器，而RARP由于使用链路层 广播则不能。在16.5节为使BOOTP穿越路由器，我们必须定义特殊的方式。如果在路由器中增加允许转发RARP请求的功能会发生什么？
16.2 我们说过，当有多个客户程序同时向一个服务器发出引导请求时，因为服务器要广播多个BOOTP应答，BOOTP客户就必须使用事务标识来使响应与请求相匹配。但在图16-3 中，事务标识为0，表示这个客户不考虑事务标识。你认为这个客户将如何将这些响应与其请求匹配。