RFC1542：Clarifications and Extensions for the Bootstrap Protocol，October 1993
本备忘录的状态
此 RFC 为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》。本备忘录的分发不受限制。
梗概
BOOTP 协议的某些方面在其原始规范中的定义相当松散。特别是对“BOOTP中继代理/BOOTP relay agents”（原名BOOTP转发代理）的行为只做了一般性的描述，客户端的行为描述也受到了一定的影响，本备忘录试图澄清和加强这些方面的规范。由于编辑过程中在 RFC 1532 中引入了一些错误，本备忘录重新发布为 RFC 1542。
此外，自编写原始规范以来，出现了新问题。本备忘录还试图解决其中的一些问题。
1、 简介
引导协议 (Bootstrap Protocol，BOOTP) 是一种基于 UDP/IP 的协议，它允许引导主机在没有用户监督的情况下动态配置自身。BOOTP 提供了一种方法来通知主机其分配的 IP 地址、引导服务器主机的 IP 地址以及要加载到内存中并执行的文件的名称 [1]。其他配置信息，如本地子网掩码、本地时间偏移、默认路由器的地址和各种 Internet 服务器的地址，也可以使用 BOOTP [2] 传送到主机。
不幸的是，最初的 BOOTP 规范 [1] 使协议的一些问题有待商榷。BOOTP 中继代理（以前称为“BOOTP 转发代理”）的确切行为没有明确规定。整个协议规范的某些部分实际上是冲突的，而其他部分则受到误解，表明需要澄清。本备忘录解决了这些问题。
自从引入 BOOTP 以来，IEEE 802.5 令牌环网络已经开发出来，这为 BOOTP 的特定消息传输范例提出了一个独特的问题。这份备忘录还为这个问题提出了解决方案。
注意：除非在本文档或后续文档中另有规定，否则本文档中指定的信息和要求也适用于 BOOTP 的扩展，例如动态主机配置协议 (Dynamic Host Configuration Protocol，DHCP) [3]。
1.1、 要求
在本备忘录中，用于定义特定要求重要性的词大写。这些话是：
“必须/MUST”
这个词或形容词“REQUIRED”表示该项目是规范的绝对要求。
“禁止/MUST NOT”
这句话的意思是该项目是规范的绝对禁止。
“应该/SHOULD”
这个词或形容词“推荐”的意思是在特定情况下可能存在合理的理由忽略这个项目，但在选择不同的课程之前，应该理解全部含义并仔细权衡案例。
“不应该/SHOULD NOT”
这句话意味着在特定情况下，当列出的行为可接受甚至有用时，可能存在正当理由，但在实施此标签描述的任何行为之前，应了解全部含义并仔细权衡案例。
“可能/MAY”
这个词或形容词“OPTIONAL”意味着这个项目是真正可选的。例如，一个供应商可能会选择包含该项目，因为特定市场需要它或因为它增强了产品；另一个供应商可能会省略相同的项目。
1.2、 术语
本备忘录使用以下术语：
BOOTREQUEST
BOOTREQUEST 消息是从 BOOTP 客户端发送到 BOOTP 服务器的 BOOTP 消息，请求配置信息。
BOOTREPLY
BOOTREPLY 消息是从 BOOTP 服务器发送到 BOOTP 客户端的 BOOTP 消息，提供配置信息。
Silently discard
本备忘录指定了 BOOTP 实体“静默丢弃”接收到的 BOOTP 消息的几种情况。这意味着实体将丢弃该消息而不进行进一步处理，并且该实体不会因此发送任何 ICMP 错误消息。然而，为了诊断问题，实体应该提供记录错误的能力，包括静默丢弃消息的内容，并且应该在统计计数器中记录事件。
1.3、 数据传输顺序
本文档中描述的报头和数据的传输顺序被解析为八位字节级别。每当图表显示一组八位字节时，这些八位字节的传输顺序就是它们在英语中的正常阅读顺序。例如，在下图中，八位字节按编号顺序传输。
每当一个八位字节表示一个数字量时，图中最左边的位是高位或最高有效位。即，标记为 0 的位是最高有效位。例如，下图表示值 170（十进制）。
类似地，每当一个多八位字节字段表示一个数字量时，整个字段的最左边的位是最高有效位。当传输多八位字节数量时，首先传输最重要的八位字节。
2、 一般问题
本节涵盖与所有 BOOTP 实体（客户端、服务器和中继代理）相关的一般问题。
2.1、 一般的 BOOTP 处理
应该对 BOOTP 消息执行以下一致性检查：
IP 总长度和 UDP 长度必须足够大，以包含 [1] 中指定的 300 个八位字节（在 UDP 数据字段中）的最小 BOOTP 标头。
注意：BOOTP 协议的未来扩展可能会增加 BOOTP 消息的大小。因此，根据 IP 总长度和 UDP 长度字段，大于 [1] 指定的最小大小的 BOOTP 消息也必须被接受。
消息的“op”（操作码）字段必须包含 BOOTREQUEST (1) 的代码或 BOOTREPLY (2) 的代码。
不满足这些一致性检查的 BOOTP 消息必须被静默丢弃。
2.2、 “flags”字段的定义
[1] 中定义的标准 BOOTP 消息格式包括位于“secs”字段和“ciaddr”字段之间的两个八位字节字段。尽管 [1] 的第 7.1 节确实提供了以下建议，但该字段仅被指定为“未使用”且其内容未指定：
“在第一次设置数据包之前，最好将整个数据包缓冲区清零；这会将所有字段置于默认状态。”
本备忘录特此将这两个八位字节字段指定为“标志/flags”字段。
本备忘录特此将“标志/flags”字段的最高有效位定义为广播 (B) 标志。该标志的语义在本备忘录的第 3.1.1 和 4.1.2 节中讨论。
“标志/flags”字段的其余位保留供将来使用。它们必须由客户端设置为零，并被服务器和中继代理忽略。
然后，“标志/flags”字段显示如下：
在这里：
B = 广播标志（在第 3.1.1 和 4.1.2 节中讨论） MBZ 必须为零（保留以备将来使用）
BOOTP 消息的格式如下所示。括号中的数字表示以八位字节表示的每个字段的大小。
2.3、 硬件地址的位排序
“chaddr” 字段中用于链路级硬件地址的位排序应该与用于客户端链路级网络上的 ARP 协议 [4] 的排序相同（假设为该网络定义了 ARP）。
“chaddr” 字段必须被保留，因为它是由 BOOTP 客户端指定的。中继代理不得反转 “chaddr” 字段的位排序，即使它碰巧在使用不同位排序的两个网络之间中继 BOOTREQUEST。
讨论：
“chaddr” 字段存在的主要原因之一是使 BOOTP 服务器和中继代理能够在不使用广播的情况下直接与客户端通信。实际上，“chaddr” 字段的内容通常用于以与普通 ARP 协议完全相同的方式创建 ARP 缓存条目。显然，只有使用对“chaddr”字段的一致解释才能实现互操作性。
作为一个实际示例，这意味着 IEEE 802.5 令牌环网络上的 BOOTP 客户端用于“chaddr”字段的位排序与 DIX 以太网网络上的 BOOTP 客户端使用的位排序相反。
2.4、 IEEE 802.5 令牌环网络上的 BOOTP
由于非透明桥接，必须对 IEEE 802.5 网络特别考虑客户端/服务器和客户端/中继代理交互。
客户端应该发送带有所有路由浏览器 RIF 的广播 BOOTREQUEST。如果他们选择这样做，这将使服务器/中继代理能够缓存返回路由。对于那些不能缓存返回路由的服务器/中继代理（例如，因为它们是无状态的），BOOTREPLY 消息应该发送到客户端的硬件地址，如从 BOOTP 消息中获取的，带有生成树根 RIF。客户端和服务器/中继代理将通过正常的 ARP 处理代码记录实际的桥接路由。
讨论：
在最简单的情况下，即未桥接的单环网络，BOOTP 协议的广播行为与以太网网络的广播行为相同。但是，BOOTP 客户端无法先验地知道 802.5 网络没有被桥接。事实上，服务器或中继代理可能也不知道。
在四种可能的场景中，只有两种是有趣的：假设 802.5 网络没有桥接，它是，假设网络是桥接的，它没有。在前一种情况下，将不使用路由信息字段 (Routing Information Field，RIF)；因此，如果服务器/中继代理位于环的另一段上，则客户端无法访问它。在后一种情况下，将使用 RIF 字段，从而在环上产生一些无关的字节。很明显，几乎无法衡量的低效率比完全无法沟通更受欢迎。
假设需要 RIF 字段，则需要确定客户端到达服务器/中继代理的最佳方法，以及返回响应的最佳方法。
3、 BOOTP 客户端行为
本节阐明了有关 BOOTP 客户端行为的各种问题。
3.1、 “flags” 字段的客户端使用
3.1.1、 BROADCAST标志
通常，BOOTP 服务器和中继代理尝试使用单播传送将 BOOTREPLY 消息直接传送到客户端。IP 目标地址（在 IP 标头中）设置为 BOOTP “yiaddr” 地址，链路层目标地址设置为 BOOTP “chaddr” 地址。不幸的是，一些客户端实现无法接收这样的单播 IP 数据报，直到它们知道自己的 IP 地址（因此我们有一个“鸡与蛋”的问题）。然而，它们通常可以接收广播 IP 数据报（那些将有效 IP 广播地址作为 IP 目的地，将链路层广播地址作为链路层目的地的数据报）。
如果客户端属于这个类别，它应该在它生成的 BOOTREPLY 消息的 “flags” 字段中设置（为 1）新定义的 BROADCAST 标志。这将为 BOOTP 服务器和中继代理提供一个提示，提示他们应该尝试向客户端广播他们的 BOOTREPLY 消息。
如果客户端没有这个限制（即它完全能够接收单播 BOOTREPLY 消息），它不应该设置 BROADCAST 标志（即它应该将 BROADCAST 标志清除为 0）。
讨论：
对协议的这一补充是旧主机实现的一种解决方法。这样的实现应该被修改，以便它们可以接收单播 BOOTREPLY 消息，因此不需要使用这种解决方法。通常，不鼓励使用此机制。
3.1.2、 “flags”字段的其余部分
“flags”字段的其余位保留供将来使用。客户端必须在它生成的所有 BOOTREQUEST 消息中将这些位设置为零。客户端必须忽略它收到的所有 BOOTREPLY 消息中的这些位。
3.2、 “secs”字段的定义
BOOTREQUEST 消息的 “secs” 字段应该表示从客户端发送它的第一个 BOOTREQUEST 消息以来经过的时间，以秒为单位。请注意，这意味着第一个 BOOTREQUEST 消息的 “secs” 字段应该设置为零。
客户端不应该将 “secs” 字段设置为所有 BOOTREQUEST 消息的常量值。
讨论：
“secs” 字段的原始定义含糊不清。不清楚它是表示自发送第一个 BOOTREQUEST 消息以来的时间还是其他时间段，例如自客户端计算机启动以来的时间。这限制了它作为 BOOTP 服务器和中继代理的策略控制机制的有用性。此外，已知某些客户端实现只是将此字段设置为常量值或使用不正确的字节顺序。不正确的字节顺序通常会让人看起来好像客户端等待的时间比实际等待的时间长得多，因此中继代理会比预期更早地（通常是立即）中继 BOOTREQUEST。这些实现错误进一步削弱了“secs”字段的有用性。这些不正确的实现应该被纠正。
3.3、 “ciaddr”和“yiaddr”字段的使用
如果 BOOTP 客户端不知道它应该使用什么 IP 地址，客户端应该将 “ciaddr” 字段设置为 0.0.0.0。如果客户端能够记住分配给它的最后一个 IP 地址，或者它已经通过某种替代机制预先配置了一个 IP 地址，则客户端可以用该 IP 地址填充“ciaddr”字段。如果客户端确实在 “ciaddr” 字段中放置了一个非零的 IP 地址，则客户端必须准备好接受传入的单播数据报寻址到该 IP 地址并响应该 IP 地址的 ARP 请求（如果该网络上使用了 ARP ）。
BOOTP 服务器可以自由分配一个不同的 IP 地址（在 “yiaddr” 字段中），而不是在 “ciaddr” 中表示的客户端。客户端应该采用”yiaddr”中指定的IP地址并尽快开始使用它。
讨论：
关于 “ciaddr” 字段的用途有多种解释，不幸的是，没有就一个正确的解释达成一致。一种解释是，如果客户端愿意接受 BOOTP 服务器分配给它的任何 IP 地址，则客户端应该始终将 0.0.0.0 放在“ciaddr”字段中，无论它是否知道其先前分配的地址。相反，如果客户端希望断言它必须具有特定的 IP 地址（例如，IP 地址是由主机管理员手动配置的，并且 BOOTP 仅用于从“供应商”获取引导文件和/或信息）字段），然后客户端将使用所需的 IP 地址填充“ciaddr”字段，并忽略“yiaddr”字段中指示的 BOOTP 服务器分配的 IP 地址。另一种解释认为，即使该地址可能不正确，客户端也始终使用其最近分配的 IP 地址（如果已知）填充“ciaddr”字段。这样的客户端仍将接受并使用 BOOTP 服务器分配的地址，如“yiaddr”字段中所示。这种解释的动机是帮助服务器识别客户端和/或将 BOOTREPLY 传递给客户端。然而，第三种（错误）解释允许客户端使用“ciaddr”来表达客户端所需的 IP 地址，即使客户端之前从未使用过该地址或当前未使用该地址。
最后的解释是不正确的，因为它可能会阻止 BOOTREPLY 到达客户端。服务器通常会将回复单播到 “ciaddr” 中给定的地址，但客户端可能尚未侦听该地址，或者客户端可能连接到不正确的子网，使得正常的 IP 路由（正确）将回复路由到不同的子网。
第二种解释也存在“不正确的子网”问题。
第一种解释似乎最安全，也最有可能促进互操作性。
3.4、 “giaddr”字段的解释
“giaddr” 字段的名称相当糟糕。它的存在是为了促进 BOOTREQUEST 消息从客户端通过 BOOTP 中继代理传输到与客户端不同的网络上的服务器。类似地，它有助于将来自服务器的 BOOTREPLY 消息通过 BOOTP 中继代理传递回客户端。在任何情况下，它都不代表客户端使用的通用 IP 路由器。BOOTP 客户端必须在它生成的所有 BOOTREQUEST 消息中将 “giaddr” 字段设置为零 (0.0.0.0)。
BOOTP 客户端不得将 BOOTREPLY 消息的“giaddr”字段解释为 IP 路由器的 IP 地址。BOOTP 客户端应该完全忽略 BOOTREPLY 消息中“giaddr”字段的内容。
讨论：
“giaddr” 字段的语义定义不明确。[1] 的第 7.5 节指出：
“如果“giaddr”（网关地址）不为零，那么数据包应该首先在那里转发，以便到达服务器。”
在这句话中，“到达”是指在 BOOTP 交换之后从客户端到服务器的通信，例如 TFTP 会话。不幸的是，“giaddr” 字段可能包含本身不是 IP 路由器的 BOOTP 中继代理的地址（根据 [1]，第 8 节，第五段），在这种情况下，它作为第一跳将毫无用处用于发送到服务器的 TFTP 数据包（因为，根据定义，非路由器不在 IP 层转发数据报）。
尽管现在被本备忘录的第 4.1.1 节禁止，但根据 [1] 的第 8 节第 6 段，“giaddr”字段可能包含广播地址。这样的地址不仅不能用作路由器地址，还可能导致客户端对广播地址进行 ARP（因为，如果客户端没有在 BOOTREPLY 消息中收到子网掩码，它将无法识别子网广播地址）。这显然是不可取的。
为了到达非本地服务器，客户端可以从“供应商信息扩展”[2]（如果存在）的“网关”子字段中获取第一跳路由器地址，或者通过 ICMP 路由器发现协议 [5] 或其他类似的机制。
3.5、 供应商信息“magic cookie”
建议 BOOTP 客户端始终使用称为“magic cookie”的四个八位字节标识符填充 BOOTREQUEST 的“vend”（供应商信息）字段的前四个八位字节。BOOTP 客户端应该这样做，即使它没有使用“vend”字段与 BOOTP 服务器通信的特殊信息。这有助于 BOOTP 服务器确定它应该在其 BOOTREPLY 消息中使用什么供应商信息格式。
如果没有使用特殊的供应商特定的magic cookie，BOOTP 客户端应该使用 [2] 中指定的点分十进制值 99.130.83.99。在这种情况下，如果客户端没有与服务器通信的信息，那么紧跟在magic cookie 之后的八位字节应该被设置为“结束/End”标签（255），并且“vend”字段的其余八位字节应该被设置为零.
讨论：
有时，不同的操作系统或网络包在不同时间（甚至同时！）在同一台机器上运行。由于放置在 “chaddr” 字段中的硬件地址可能相同，来自同一台机器上完全不同的 BOOTP 客户端的 BOOTREQUEST 可能很难让 BOOTP 服务器区分。如果客户端在其 BOOTREQUEST 中包含一个magic cookie，服务器至少会知道客户端期望什么格式，并且可以在相应的 BOOTREPLY 消息中理解。
4、 BOOTP 中继代理
在许多情况下，BOOTP 客户端及其关联的 BOOTP 服务器并不位于同一 IP 网络或子网上。在这种情况下，需要某种第三方代理在客户端和服务器之间传输 BOOTP 消息。这种代理最初被称为“BOOTP 转发代理”。但为了避免与IP路由器的IP转发功能混淆，特采用“BOOTP中继代理”这一名称代替。
讨论：
BOOTP 中继代理执行的任务不同于 IP 路由器的正常 IP 转发功能。虽然路由器通常或多或少地透明地在网络之间切换 IP 数据报，但更恰当的做法是认为 BOOTP 中继代理接收 BOOTP 消息作为最终目的地，然后因此生成新的 BOOTP 消息。中继代理实现简单地“像常规数据包一样直通”转发 BOOTP 消息是不正确的。
这种中继代理功能最方便地位于互连客户端和服务器的路由器中，但也可以位于直接连接到客户端子网的主机中。
任何提供 BOOTP 中继代理功能的 Internet 主机或路由器都必须符合本备忘录中的规范。
4.1、 中继代理的一般 BOOTP 处理
主机或路由器的逻辑 BOOTP 中继代理会考虑对所有本地传递的 UDP 消息（其 UDP 目标端口号为 BOOTPS (67)）进行特殊处理。
在主机的情况下，本地传送的数据报只是该主机正常接收的所有数据报，即广播和多播数据报以及寻址到该主机 IP 地址的单播数据报。
在路由器的情况下，本地传递的数据报是广播和多播数据报以及寻址到该路由器 IP 地址的单播数据报。这些是路由器应被视为最终目的地而不是中间交换节点的数据报。因此，具有与任何路由器 IP 地址都不匹配的 IP 目的地的单播数据报不会被路由器的逻辑 BOOTP 中继代理考虑处理。
主机和路由器通常需要默默地丢弃包含非法 IP 源地址的传入数据报。这通常称为“火星地址过滤/Martian address filtering”。这些非法地址之一是 0.0.0.0（或者实际上是网络 0 上的任何地址）。但是，支持 BOOTP 中继代理的主机或路由器必须接受本地传送到 IP 源地址为 0.0.0.0 的中继代理 BOOTREQUEST 消息。来自合法 IP 源地址的 BOOTREQUEST 消息也必须被接受。
中继代理必须默默地丢弃任何接收到的 UDP 消息，其 UDP 目标端口号为 BOOTPC (68)。
讨论：
应该不需要中继代理来处理寻址到 BOOTPC 端口的消息。仔细阅读原始 BOOTP 规范 [1] 会发现这一点。然而，一些中继代理实现错误地中继了此类消息。
第 2.1 节中指定的一致性检查应该由中继代理执行。不满足这些一致性检查的 BOOTP 消息必须被静默丢弃。
4.1.1、 引导请求消息
必须存在某种配置机制来启用或禁用 BOOTREQUEST 消息的中继。默认情况下必须禁用中继。
当 BOOTP 中继代理收到 BOOTREQUEST 消息时，它可以使用请求的 “secs”（自客户端开始启动以来的秒数）字段的值作为决定是否中继请求的因素。如果实现了这样的策略机制，它的阈值应该是可配置的。
讨论：
迄今为止，BOOTP 协议的此功能不一定有用。有关讨论，请参阅第 3.2 节。
中继代理必须静默丢弃 “hops” 字段超过值 16 的 BOOTREQUEST 消息。如果网络管理员需要，应该提供一个配置选项来将此阈值设置为较小的值。可配置阈值的默认设置应该是 4。
如果中继代理决定中继请求，它必须检查“giaddr”（“网关”IP 地址）字段。如果此字段为零，则中继代理必须使用接收请求的接口的 IP 地址填充此字段。如果接口有多个逻辑关联的 IP 地址，中继代理应该选择一个与该接口关联的 IP 地址，并一致地将它用于它中继的所有 BOOTP 消息。如果 “giaddr” 字段包含一些非零值，则不得修改 “giaddr” 字段。在任何情况下，中继代理都不得使用 [1]（第 8 节，第六段）中建议的广播地址填充“giaddr”字段。
“hops” 字段的值必须递增。
所有其他 BOOTP 字段必须保持完整。
此时，请求被中继到其新目的地（或多个目的地）。这个目的地必须是可配置的。此外，这个目的地配置应该独立于任何其他所谓的“广播转发器”的目的地配置（例如，对于基于 UDP 的 TFTP、DNS、时间等协议）。
讨论：
网络管理器可能希望中继目的地是 IP 单播、多播、广播或某种组合。目标 IP 地址的可配置列表提供了良好的灵活性。鼓励更灵活的配置方案。例如，可能需要发送到特定物理接口上的有限广播地址 (255.255.255.255)。但是，如果 BOOTREQUEST 消息是作为广播接收的，则中继代理不得在它来自的物理接口上重新广播 BOOTREQUEST。
中继代理必须对它从给定客户端中继的所有 BOOTREQUEST 消息使用相同的目的地（或一组目的地）。
讨论：
至少一个已知的中继代理实现使用循环方案来提供跨多个 BOOTP 服务器的负载平衡。每次收到新的 BOOTREQUEST 消息时，它都会将该消息中继到服务器列表中的下一个 BOOTP 服务器。因此，使用此中继代理，来自给定客户端的多个连续 BOOTREQUEST 消息将被传送到不同的服务器。
不幸的是，这个善意的方案对 DHCP [3] 以及可能依赖于客户端和服务器之间多次交换 BOOTREQUEST 和 BOOTREPLY 消息的 BOOTP 协议的其他变体的反应很差。因此，来自给定客户端的所有 BOOTREQUEST 消息必须中继到相同的目的地（或一组目的地）。
在提供一些负载平衡好处的同时满足此要求的一种方法是散列客户端的链路层地址（或一些其他可靠的客户端识别信息）并使用生成的散列值来选择适当的中继目的地（或一组目的地） .当然，最简单的解决方案是不使用负载平衡方案，而只是将所有收到的 BOOTREQUEST 消息中继到同一目的地（或一组目的地）。
当将请求传输到其下一个目的地时，中继代理可以将 IP 生存时间字段设置为中继代理发起的新数据报的默认值，或者将原始 BOOTREQUEST 的 TTL 递减（至少）一。
讨论：
作为防止 BOOTREQUEST 循环的额外预防措施，最好使用从原始 BOOTREQUEST 递减的 TTL。不幸的是，这在某些实现中可能很难做到。
如果 BOOTREQUEST 具有 UDP 校验和（即 UDP 校验和非零），则必须在传输请求之前重新计算校验和。
4.1.2、 引导消息
BOOTP 中继代理仅将 BOOTREPLY 消息中继到 BOOTP 客户端。BOOTP 服务器负责将 BOOTREPLY 消息直接发送到“giaddr”字段中标识的中继代理。因此，中继代理可能会假设它接收到的所有 BOOTREPLY 消息都是针对其直接连接网络上的 BOOTP 客户端的。
当中继代理收到 BOOTREPLY 消息时，它应该检查 BOOTP “giaddr”、“yiaddr”、“chaddr”、“htype” 和 “hlen” 字段。这些字段应该为中继代理提供足够的信息以将 BOOTREPLY 消息传递给客户端。
“giaddr” 字段可用于标识必须从其发送回复的逻辑接口（即与 BOOTP 客户端连接到同一网络的主机或路由器接口）。如果“giaddr”字段的内容与中继代理直接连接的逻辑接口之一不匹配，则必须静默丢弃 BOOTREPLY 消息。
“htype”、”hlen” 和 “chaddr” 字段提供了 ARP 协议 [4] 和指定号码文档 [6] 中定义的客户端的链路层硬件类型、硬件地址长度和硬件地址。“yiaddr” 字段是客户端的 IP 地址，由 BOOTP 服务器分配。
中继代理应该检查新定义的 BROADCAST 标志（有关更多信息，请参阅第 2.2 和 3.1.1 节）。如果此标志设置为 1，则回复应作为 IP 广播发送，使用 IP 限制广播地址 255.255.255.255 作为 IP 目标地址和链路层广播地址作为链路层目标地址。如果 BROADCAST 标志被清除 (0)，则回复应该作为 IP 单播发送到“yiaddr”字段指定的 IP 地址和“chaddr”字段指定的链路层地址。如果单播是不可能的，回复可以作为广播发送，在这种情况下，它应该被发送到使用 IP 限制广播地址 255.255.255.255 作为 IP 目的地址的链路层广播地址。
讨论：
向协议添加 BROADCAST 标志是一种解决方法，可帮助促进与某些客户端实现的互操作性。
请注意，由于 “flags” 字段之前在 [1] 中只是简单地定义为“未使用”字段，因此旧的客户端或服务器实现可能会意外且不知不觉地设置新的 BROADCAST 标志。实际上预计此类实现将很少见（大多数实现似乎将此字段归零），但仍然必须考虑与此类实现的交互。如果旧客户端或服务器确实错误地将 BROADCAST 标志设置为 1，则符合要求的中继代理将向相应的客户端生成广播 BOOTREPLY 消息。BOOTREPLY 消息仍应正确到达客户端，但需要进行一次（否则是不必要的）额外广播。然而，这并不比总是广播其 BOOTREPLY 消息的服务器或中继代理更糟糕。
应该更正意外设置 BROADCAST 标志的旧客户端或服务器实现，以正确遵守此新规范。
所有 BOOTP 字段必须保持完整。中继代理在将 BOOTREPLY 消息中继到客户端时不得修改 BOOTREPLY 消息的任何 BOOTP 字段。
回复必须将其 UDP 目标端口设置为 BOOTPC (68)。
如果 BOOTREPLY 具有 UDP 校验和（即 UDP 校验和非零），则必须在传输回复之前重新计算校验和。
5、 BOOTP 服务器行为
本节对 BOOTP 服务器的行为进行了说明。
5.1、 BOOTREQUEST消息的接收
所有接收到的 UDP 目标端口号为 BOOTPS (67) 的 UDP 消息都被 BOOTP 服务器考虑处理。
主机和路由器通常需要默默地丢弃包含非法 IP 源地址的传入数据报。这通常称为“火星地址过滤/Martian address filtering”。这些非法地址之一是 0.0.0.0（或者实际上是网络 0 上的任何地址）。但是，支持 BOOTP 服务器的主机或路由器必须接受本地传送到 IP 源地址为 0.0.0.0 的服务器的 BOOTREQUEST 消息。来自合法 IP 源地址的 BOOTREQUEST 消息也必须被接受。
BOOTP 服务器必须默默地丢弃任何接收到的 UDP 消息，其 UDP 目标端口号是 BOOTPC (68)。
讨论：
应该不需要 BOOTP 服务器来处理寻址到 BOOTPC 端口的消息。仔细阅读原始 BOOTP 规范 [1] 会发现这一点。
第 2.1 节中指定的一致性检查应该由 BOOTP 服务器执行。不满足这些一致性检查的 BOOTP 消息必须被静默丢弃。
5.2、 “secs”字段的使用
当 BOOTP 服务器收到 BOOTREQUEST 消息时，它可以使用请求的“secs”（自客户端开始启动以来的秒数）字段的值作为决定是否和/或如何回复请求的因素。
讨论：
迄今为止，BOOTP 协议的此功能不一定有用。有关讨论，请参阅第 3.2 节。
5.3、 “ciaddr”字段的使用
对于应参考第 3.3 节的“ciaddr”字段，客户有多种解释。BOOTP 服务器应该准备好处理这些不同的解释。通常，“ciaddr”字段不应该被信任为识别客户端的唯一密钥；“ciaddr”、”chaddr”、”htype” 和 “hlen” 字段的内容，以及可能的其他信息（可能在 “file” 和 “vend” 字段中）都应该在决定如何响应时一起考虑给定的客户。
BOOTP 服务器应该保留 BOOTREPLY 消息中“ciaddr”字段的内容；BOOTREPLY 消息中“ciaddr”的内容应该与相应 BOOTREQUEST 消息中“ciaddr”的内容完全匹配。
讨论：
有人建议客户端可能希望使用 “ciaddr” 的内容来进一步验证特定的 BOOTREPLY 消息确实是为它准备的。
5.4、 BOOTREPLY 消息的传递策略
一旦 BOOTP 服务器创建了适当的 BOOTREPLY 消息，该 BOOTREPLY 消息必须正确传送到客户端。
服务器应该首先检查“ciaddr”字段。如果”ciaddr”字段非零，BOOTREPLY消息应该作为IP单播发送到”ciaddr”字段中标识的IP地址。UDP 目标端口必须设置为 BOOTPC (68)。但是，服务器必须意识到第 3.3 节中确定的问题。服务器可以选择忽略 “ciaddr” 字段并像 “ciaddr” 字段包含 0.0.0.0 一样（因此继续下面的其余交付算法）。
服务器应该接下来检查“giaddr”字段。如果此字段非零，服务器应该将 BOOTREPLY 作为 IP 单播发送到“giaddr”字段中标识的 IP 地址。UDP 目标端口必须设置为 BOOTPS (67)。这个动作会将 BOOTREPLY 消息直接传递给离客户端最近的 BOOTP 中继代理；然后中继代理将执行对客户端的最终交付。如果 BOOTP 服务器事先知道特定客户端无法接收单播 BOOTREPLY 消息（例如，网络管理器已明确配置服务器具有此类知识），则服务器可以设置新定义的 BROADCAST 标志以指示中继代理应该广播BOOTREPLY 消息给客户端。否则，服务器必须保留 BROADCAST 标志的状态，以便中继代理可以正确地对其进行操作。
如果“giaddr”字段设置为 0.0.0.0，则客户端位于与 BOOTP 服务器相同的网络之一。服务器应该检查新定义的 BROADCAST 标志（有关更多信息，请参阅第 2.2、3.1.1 和 4.1.2 节）。如果此标志设置为 1 或服务器事先知道客户端无法接收单播 BOOTREPLY 消息，则回复应作为 IP 广播发送，使用 IP 限制广播地址 255.255.255.255 作为 IP 目标地址和链接-层广播地址作为链路层目的地址。如果 BROADCAST 标志被清除 (0)，则回复应该作为 IP 单播发送到“yiaddr”字段指定的 IP 地址和“chaddr”字段指定的链路层地址。如果单播是不可能的，则回复可以作为广播发送，在这种情况下，它应该使用 IP 限制广播地址 255.255.255.255 作为 IP 目标地址发送到链路层广播地址。在任何情况下，UDP 目标端口都必须设置为 BOOTPC (68)。
讨论：
向协议添加 BROADCAST 标志是一种解决方法，可帮助促进与某些客户端实现的互操作性。
下表总结了基于 BOOTREQUEST 消息中的信息的 BOOTREPLY 消息的服务器交付决策：
B = BROADCAST flag X = Don”t care normal = 使用正常 IP 路由机制和/或 ARP 从给定的 IP 目的地确定任何其他正常数据报
致谢
作者要感谢 Gary Malkin 在“BOOTP over IEEE 802.5 Token Ring Networks”部分的贡献，以及 Steve Deering 对与 “giaddr” 领域相关问题的观察。
Ralph Droms 和 IETF 动态主机配置和路由器要求工作组的许多成员为本备忘录提供了想法并鼓励编写它。
Philip Almquist 和 David Piscitello 提供了许多有用的建议，以提高本备忘录的清晰度、准确性和组织性。这些贡献得到了亲切的承认。
参考
[1] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford University and Sun Microsystems, September 1985. [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, USC/Information Sciences Institute, August 1993. This RFC is occasionally reissued with a new number. Please be sure to consult the latest version. [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, Bucknell University, October 1993. [4] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37, RFC 826, MIT, November 1982. [5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991. [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July, 1992. This RFC is periodically reissued with a new number. Please be sure to consult the latest version.
安全注意事项
有许多因素使当前形式的 BOOTP 非常不安全。BOOTP 直接建立在 UDP 和 IP 之上，而这些 UDP 和 IP 本身尚不安全。此外，BOOTP 通常旨在使远程和/或无盘主机的维护更容易。虽然并非不可能，但使用密码或密钥配置此类主机可能很困难且不方便。这使得很难在服务器和客户端之间提供任何形式的合理身份验证。
可以轻松设置未经授权的 BOOTP 服务器。然后，此类服务器可以向客户端发送虚假的和潜在的破坏性信息，例如不正确或重复的 IP 地址、不正确的路由信息（包括欺骗路由器等）、不正确的域名服务器地址（例如欺骗名称服务器）等等。显然，一旦植入这种“种子”错误信息，攻击者就可以进一步破坏受影响的系统。
未经授权的 BOOTP 中继代理可能会出现一些与未经授权的 BOOTP 服务器相同的问题。
恶意 BOOTP 客户端可以伪装成合法客户端并检索针对这些合法客户端的信息。在使用资源动态分配的情况下，恶意客户端可以为自己声明所有资源，从而拒绝向合法客户端提供资源。
