RFC951引導协议(BOOTP).doc

组织：中国互动出版网（/） RFC文档中文翻译计划（/compters/emook/aboutemook.htm） E-mail：ouyang@ 译者：金涛（piex albertxu@） 译文发布时间：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 概述 本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允许客户端通过使用相邻的网关从几跳外的服务器上引导。请看下面通过网关引导的章节。 这部分协议不需求客户端部分做特