rfcrfc951.txt

本程序为在linux下实现FTP传输文件的实现

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：[e-mail]
译者：金涛（piex  [e-mail]）
译文发布时间：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




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允许客户端通过使用相邻的网关从几跳外的服务器上引导。请看下面'通过网关
引导'的章节。
	      这部分协议不需求客户端部分做特定的动作。
	      实现是可选的，网关和服务器需要一些额外的代码。
	
2	包格式
	
	   除非另外指出，所有显示的数字都是十进制的。
	   简化起见，假设BOOTP包不会被分片。
	   所有数字的字段使用标准网络字节顺序。即，先传送高位比特。
	
	   在引导请求的IP头中，客户端如果知道就填自己的IP源地址，否则填0。当服务器地址不知
道时，
	   IP目的地址将是广播地址255.255.255.255。这个地址意味着'在本地网上广播，我不知道我的
网络号'[4]。
	
	   UDP头包含源和目的端口号。BOOTP协议使用两个保留的端口号，'BOOTP客户端' (68)
	   和'BOOTP服务器' (67)。
	   客户使用'BOOTP服务器'做为目的端口发送请求；这通常是广播。
	   服务器使用'BOOTP客户端'做为目的端口发送应答；取决于服务器的核心或驱动设备，这可
能是也可能不是广播
	   （在下面'鸡和蛋的问题'标题的章节中深入解释）。
	   使用两个保留的端口的原因是当引导应答必须广播到客户端避免'叫醒'并且调度BOOTP服
务器进程。
	   因为服务器和其它主机都不会侦听'BOOTP客户端'端口，
	   所有进入的广播报文将在核心级别过滤掉。
	   我们不能简单地允许客户端找一个随机端口号做为UDP源端口字段；因为服务器应答可能
是广播，
	   一个随机选择的端口号可能搞乱其它恰巧在侦听那个端口的主机。
	
	   UDP长度字段设置成UDP长度加BOOTP部分的包。
	   UDP校验和可以由客户端（或服务器）按照需要设置成0，以避免PROM实现中额外的费用。
	   在下面的'包处理'章节中'[UDP校验和]'短语用来表示校验和可能被验证/计算。
	   
	
	      字段  字节数	描述
	      -----   -----   -----------
	
	         op      1       packet op code / message type. 包操作码/消息类型
	                         1 = BOOTREQUEST(引导请求), 2 = BOOTREPLY(引导应答)
	
	         htype   1       hardware address type, 硬件地址类型
	                         see ARP section in "Assigned Numbers" RFC. 请看"Assigned 
Numbers" RFC中的ARP章节
	                         '1' = 10mb ethernet 10M以太网
	
	         hlen    1       hardware address length 硬件地址长度
	                         (eg '6' for 10mb ethernet). 例如'6'是10M以太网
	
	         hops    1       client sets to zero, 客户端设置成0
	                         optionally used by gateways   在跨越网关引导时网关可选择使用
	                         in cross-gateway booting.
	
	         xid     4       transaction ID, a random number,
	                         used to match this boot request with the
	                         responses it generates.  事务ID，一个随机数，用来匹配引用请求
和应答
	
	         secs    2       filled in by client, seconds elapsed since
	                         client started trying to boot.  由客户端填写，客户端引导开始后的
过去的秒数
	
	         --      2       unused未使用
	
	         ciaddr  4       client IP address;客户端IP地址，
	                         filled in by client in bootrequest if known.如果客户端知道就在引导
请求中填入
	
	         yiaddr  4       'your' (client) IP address;'你的'（客户端）IP地址
	                         filled by server if client doesn't
	                         know its own address (ciaddr was 0).如果客户端不知道它的地址
（ciaddr是0），服务器填入
	
	         siaddr  4       server IP address;服务器IP地址
	                         returned in bootreply by server.由服务器在引导应答返回
	
	         giaddr  4       gateway IP address,网关IP地址
	                         used in optional cross-gateway booting.在跨越网关引导中可以选择
使用
	
	         chaddr  16      client hardware address,客户端硬件地址
	                         filled in by client.由客户端填写
	
	         sname   64      optional server host name,可选的服务器主机名
	                         null terminated string. 空结束的字符串
	
	         file    128     boot file name, null terminated string; 引导文件名，空结束的字符串
	                         'generic' name or null in bootrequest, 在引导请求中使用'通用'名称
或空
	                         fully qualified directory-path         是引导应答中使用确切的目
录路径名称
	                         name in bootreply.
	
	         vend    64      optional vendor-specific area,  可选的卖主指定的区域，
	                         e.g. could be hardware type/serial on request, 例如，可以是请求硬件
类型/序列，
	                         or 'capability' / remote file system handle    或应答的性能/远端文
件系统句柄。 
	                         on reply.  This info may be set aside for use  这些信息留给第三方
分析引导或核心（程序）使用。
	                         by a third phase bootstrap or kernel.
	
	
3	鸡和蛋的问题
	
	   如果客户端不知道自己IP地址，服务器怎么发送IP报文到客户端。
	   无论何时一条引导应答被发送，发送设备执行下列操作：
	
	      1.如果客户端知道自己的IP地址（'ciaddr'字段非零），
	      因为客户端能够回应ARPs [5]，那么IP能够正常发送。
	
	      2.如果客户端还不知道自己的IP地址（ciaddr是零），
	      客户端就不能回应引导应答发送程序回的ARPs。这时有两种选择：
	
	         a.如果发送程序有必需的核心或驱动钩子程序来人工建立ARP地址缓冲条目，
	
	         就可以使用'chaddr'和'yiaddr'字段填入一个条目。当然，这个条目象正常ARP建立的
其它条目一样有一个生命时间，
	         引导应答的发送程序就能够简单地发送引导应答到客户端的IP地址了。UNIX (4.2 
BSD)有这种功能。
	
	         b.如果发送程序缺少这些核心钩子程序，就只能简单发送引导应答到相应接口的广播
地址。
	         这只是在前面情况外的额外的广播。
	
4	ARP在客户端使用
	
	   客户端PROM必须包含一个ARP的简单实现，例如，地址缓冲能够容纳一个条目。
	   这将允许客户端在知道IP地址和引导文件名后执行第二阶段引导（TFTP）。
	
	   任何时候客户端应该准备回应一个自己IP到硬件地址映射的ARP请求（如果知道）以接收
TFTP或BOOTP应答。
	
	   因为引导应答将包含服务器/网关的硬件源地址（在硬件中封装），客户端可以
	   避免发送一条ARP请求来申请后续的TFTP阶段使用的服务器/网关IP地址。
	   但这应该只是一种特殊情况，因为上面描述的只有第二阶段的引导仍然允许。
	
5	与RARP对照
	
	   提议客户端使用一个早先的协议，反向地址解析协议(RARP) [1]来通过它的硬件地址确定自
己的IP地址。
	   但RARP的劣势是它是一个硬件链路层的协议（不是基于IP/UDP）。
	   这意味着RARP只能在包含特殊的为访问原始报文修改的核心和驱动的主机上实现。
	   因为现在存在不同组织维护的许多网络核心，一个不要求修改核心的引导协议是一个确定
的优势。
	
	   BOOTP除了上述章节描述的有用的特性外，还提供硬件到IP地址的查询功能。
	
6	包处理
6.1   客户端传送
	
	      在第一次建立包前，最好把整个包的缓冲区清零；
	      这将所有的字段设置成默认状态。任何客户端建立包中的下列字段。
	
	      IP目的地址被设置成255.255.255.255（广播地址）或服务器的IP地址（如果知道）。
	      IP源地址和'ciaddr'设置成客户端IP地址（如果知道），或者0。UDP头使用适当的长度设
置；
	      源端口='BOOTP客户端'端口，目标端口='BOOTP服务器'端口。