ImageVerifierCode 换一换
格式:DOCX , 页数:17 ,大小:25.13KB ,
资源ID:10517456      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/10517456.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(RFC951引导协议BOOTP.docx)为本站会员(b****8)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

RFC951引导协议BOOTP.docx

1、RFC951引导协议BOOTP组织:中国互动出版网(http:/www.china-RFC文档中文翻译计划(http:/www.china-E-mail:ouyangchina-译者:金涛(piex albertxu)译文发布时间:2001-07-05版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须保留本文档的翻译及版权信息。Network Working Group Bill Croft (Stanford University)Request for Comments: 951 John Gilmore (Sun Microsystems) Septembe

2、r 1985引导协议(BOOTP)(RFC951-BOOTSTRAP PROTOCOL (BOOTP)本备忘录的状态 本RFC文档向ARPA-Internet社区提供一个被提议的协议,需要进一步进行讨论和建议以得到改进。 本文档无发布限制。目录1 概述 22 包格式 33 鸡和蛋的问题 64 ARP在客户端使用 75 与RARP对照 76 包处理 76.1 客户端传送 76.2 客户端重传策略 96.3 服务器接收BOOTREQUEST(引导请求) 96.4 服务器/网关接收BOOTREPLY(引导应答) 116.5 客户端接收 117 通过网关引导 118 样例BOOTP服务器数据库 129

3、 致谢 1410 参考文献 141 概述 本RFC描述一种IP/UDP引导协议(BOOTP),允许一个无盘客户端发现自己的IP地址, 服务器主机的地址,和装入一个指定名称的文件到内存并且运行。引导操作有两阶段组成。 本RFC描述第一个阶段:分配地址和选择引导文件。 在获得地址和文件名信息后,就进入引导的第二个阶段:文件传送。 文件传送一般使用TFTP协议9,因为两个阶段均驻留在客户端的PROM中。 但BOOTP也能够与其它协议如SFTP或FTP一起工作。 我们建议客户端的PROM软件提供一种无须用户交互的完整的引导方式。 这是一种无人值守的上电启动方式。 必须提供一种机制来让用户手工提供地址和

4、文件名信息旁路BOOTP协议直接进入文件传送阶段。 如果提供非可变存储,我们建议在那里保存设置以旁路BOOTP协议直到这些设置导致文件传送阶段失败。 如果缓存的信息失败,引导后退到第一阶段并使用BOOTP。 协议的要点: 1.使用了一个单独的包交换(信息)。使用超时机制直到收到应答。 双向使用相同的包字段结构。使用(最大可能长度的)固定长度的字段来简化结构定义和分析。 2.一个opcode字段包含两个值。客户端广播一个引导请求(bootrequest)包。 服务器应答一个引导应答(bootreply)包。bootrequest包含客户端的硬件地址,如果知道,还包含它的IP地址。 3.请求可以包

5、含客户端指定的响应服务器的名称。 这样客户端可以强制从一个指定的主机引导。(如果一个相同的引导文件存在多种版本或服务器在一个远距离的网络/域。) 客户端不必处理名称/域服务,这个功能推到了BOOTP服务器。 4.请求可以包含通用(generic)引导文件名。例如unix或ethertip。但服务器发送 引导应答时,它使用对应的引导文件的确切的路径名称来取代这个字段。 服务器查询客户端的地址和请求文件名相关的数据库,以使用客户端自定义的特定引导文件确定这个文件名称。 如果引导请求文件名是空字符串,服务器返回一个带有客户端加载的默认文件的文件名字段。 5.客户端不知道它们的IP地址的情况下, 服务

6、器必须有一个硬件地址和IP地址对应的数据库。 这个客户端IP地址被放在引导应答的(对应)字段中。 6.某些网络拓朴(如斯坦福的网络)可能在一个物理网上没有一个直接可以访问的TFTP服务器 (例如在某些网上的所有的网关和主机都可能是无盘的)。 BOOTP允许客户端通过使用相邻的网关从几跳外的服务器上引导。请看下面通过网关引导的章节。 这部分协议不需求客户端部分做特定的动作。 实现是可选的,网关和服务器需要一些额外的代码。2 包格式 除非另外指出,所有显示的数字都是十进制的。 简化起见,假设BOOTP包不会被分片。 所有数字的字段使用标准网络字节顺序。即,先传送高位比特。 在引导请求的IP头中,客

7、户端如果知道就填自己的IP源地址,否则填0。当服务器地址不知道时, IP目的地址将是广播地址255.255.255.255。这个地址意味着在本地网上广播,我不知道我的网络号4。 UDP头包含源和目的端口号。BOOTP协议使用两个保留的端口号,BOOTP客户端 (68) 和BOOTP服务器 (67)。 客户使用BOOTP服务器做为目的端口发送请求;这通常是广播。 服务器使用BOOTP客户端做为目的端口发送应答;取决于服务器的核心或驱动设备,这可能是也可能不是广播 (在下面鸡和蛋的问题标题的章节中深入解释)。 使用两个保留的端口的原因是当引导应答必须广播到客户端避免叫醒并且调度BOOTP服务器进程

8、。 因为服务器和其它主机都不会侦听BOOTP客户端端口, 所有进入的广播报文将在核心级别过滤掉。 我们不能简单地允许客户端找一个随机端口号做为UDP源端口字段;因为服务器应答可能是广播, 一个随机选择的端口号可能搞乱其它恰巧在侦听那个端口的主机。 UDP长度字段设置成UDP长度加BOOTP部分的包。 UDP校验和可以由客户端(或服务器)按照需要设置成0,以避免PROM实现中额外的费用。 在下面的包处理章节中UDP校验和短语用来表示校验和可能被验证/计算。 字段 字节数 描述 - - - op 1 packet op code / message type. 包操作码/消息类型 1 = BOOT

9、REQUEST(引导请求), 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 g

10、ateways 在跨越网关引导时网关可选择使用 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

11、 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 doesnt know its own address (ciaddr was 0).如果客户端不知道它的地址(ciaddr是0),服务器填入 siaddr 4 server IP address;服务器IP地址 returned in bootreply by serv

12、er.由服务器在引导应答返回 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; 引

13、导文件名,空结束的字符串 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 或应答的性能/远端文

14、件系统句柄。 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。这时有两种选择:

15、a.如果发送程序有必需的核心或驱动钩子程序来人工建立ARP地址缓冲条目, 就可以使用chaddr和yiaddr字段填入一个条目。当然,这个条目象正常ARP建立的其它条目一样有一个生命时间, 引导应答的发送程序就能够简单地发送引导应答到客户端的IP地址了。UNIX (4.2 BSD)有这种功能。 b.如果发送程序缺少这些核心钩子程序,就只能简单发送引导应答到相应接口的广播地址。 这只是在前面情况外的额外的广播。4 ARP在客户端使用 客户端PROM必须包含一个ARP的简单实现,例如,地址缓冲能够容纳一个条目。 这将允许客户端在知道IP地址和引导文件名后执行第二阶段引导(TFTP)。 任何时候客户

16、端应该准备回应一个自己IP到硬件地址映射的ARP请求(如果知道)以接收TFTP或BOOTP应答。 因为引导应答将包含服务器/网关的硬件源地址(在硬件中封装),客户端可以 避免发送一条ARP请求来申请后续的TFTP阶段使用的服务器/网关IP地址。 但这应该只是一种特殊情况,因为上面描述的只有第二阶段的引导仍然允许。5 与RARP对照 提议客户端使用一个早先的协议,反向地址解析协议(RARP) 1来通过它的硬件地址确定自己的IP地址。 但RARP的劣势是它是一个硬件链路层的协议(不是基于IP/UDP)。 这意味着RARP只能在包含特殊的为访问原始报文修改的核心和驱动的主机上实现。 因为现在存在不同

17、组织维护的许多网络核心,一个不要求修改核心的引导协议是一个确定的优势。 BOOTP除了上述章节描述的有用的特性外,还提供硬件到IP地址的查询功能。6 包处理6.1 客户端传送 在第一次建立包前,最好把整个包的缓冲区清零; 这将所有的字段设置成默认状态。任何客户端建立包中的下列字段。 IP目的地址被设置成255.255.255.255(广播地址)或服务器的IP地址(如果知道)。 IP源地址和ciaddr设置成客户端IP地址(如果知道),或者0。UDP头使用适当的长度设置; 源端口=BOOTP客户端端口,目标端口=BOOTP服务器端口。 op设置成1,BOOTREQUEST(引导请求)。htype

18、设置成在Assigned Numbers RFC ARP章节中分配的硬件地址类型。 hlen设置成硬件地址长度,例如,10M以太网是6。 xid设置成一个随机事务ID。secs设置成客户端引导开始后过去的秒数。 这个让服务器知道客户端已经试了多长时间了。 当数字变大,某些服务器可能更多注意这个客户端提供不同的服务。 如果客户端缺少一个适当的时钟,它可以使用循环定时器建立一个粗略的估计值。 或者它可以选择简单发送使用一个固定值如100秒的字段。 如果客户端知道IP地址,ciaddr(和IP源地址)设置成这个值。 chaddr使用客户端硬件地址填写。 如果客户端希望限制从一个特定服务器名引导,就可

19、以在sname中放一个空结束的字符串。 使用的名字应该是对应的主机的正当的名字或别名。 客户端在填写file文件名字段是有许多选择。 如果设置成空,意味着我向使用默认的文件来引导我的机器。一个空文件名也意味着 我只对找到客户端/服务器/网关的IP地址感兴趣,我不在乎文件名。 这个字段也可以是一个通用名字入unix或gateway;这意味着 使用命名的程序配置来引导我的机器。最后这个字段可以是确切的目录路径名字。 vend字段可以由客户端填写卖主的字符串或结构。例如可以填写机器硬件类型或序列号。 但BOOTP服务器的操作应该不依赖与这些存在的信息。 如果使用了vend,推荐在vend中第一个项目

20、为一个4字节的魔术字(magic number)。 这让服务器确定在这个字段中它看到什么类型的信息。 数值可以由通常的魔术字过程分配,你挑一个,它就成为魔术字。 引导应答使用一个与引导请求不同的魔术字以允许客户端按照应答信息进行特殊的动作。 UDP校验和6.2 客户端重传策略 在一长段时间内没有收到应答,客户端应该重传请求。 时间间隔必须仔细选择不要引起网络风暴。 可以考虑一个包含100台机器的网络在电源故障后发生的情况。 简单的每四秒重传请求将淹没网络。 一个可能的策略,你可能考虑指数级的补偿,象以太网在碰撞时那样。 例如第一个包在0:00,第二个在:04,接着:08,接着:16,:32,:

21、64。 你应该随机化每个时间;这就象以太网规格那样以一个掩码与一个随机数进入第一次补偿。 在每次后续的补偿中,掩码增长一个比特。 这样在每次补偿中平均延迟加倍。 在平均补偿到达60秒后,就不再增长了,但仍然随机化。 在每次重传前,客户端应该修改secs字段。UDP校验和6.3 服务器接收BOOTREQUEST(引导请求) UDP校验和 如果UDP目的端口不匹配BOOTP服务器端口,丢弃这个包。 如果服务器名字字段(sname)是空(没有指定特定的服务器),或者sname是指定的并且匹配我们的名字或别名, 继续包的处理。 如果sname字段是指定的,但不匹配我们,那么有多种选择: 1.你可以选择

22、简单丢弃这个包。 2.如果查询sname的名称显示它在一个网络中,丢弃这个包。 3.如果sname在不同的网络中,你可以选择转发这个包到那个地址。 如果这样,检查giaddr(网关地址)字段。如果giaddr是0,填入我的地址或可以用来到达那个网络的网关的地址。 然后转发这个包。 如果客户端IP地址(ciaddr)是0,那么客户端不知道自己的IP地址。 尝试在我们的数据库中查找客户端的硬件地址(chaddr, hlen, htype)。 如果没有匹配,丢弃这个包。否则我们现在对这个客户端有一个IP地址;填入yiaddr(你的IP地址)字段。 我们现在检查引导文件名字段(文件)。如果客户端不关注

23、文件名或想要默认引导文件,这个字段是空。 如果这个字段非空,可以将它和客户端的IP地址做为数据库的查询关键字。 如果有默认的文件或通用文件(可能由客户端地址做为索引)或一个匹配的指定的路径名称, 然后在file字段中填入选择的引导文件的指定的路径名称。 如果字段是非空并且没有匹配,那么客户端要一个我们没有的文件,丢弃这个包,也许其它BOOTP服务器有这个文件。 卖主指定的数据字段vend现在应该检查了。如果提供一种可识别类型的数据, 应该进行客户端指定的动作,并且回应要填入应答包中的vend数据字段。 例如,一个工作站客户端可能提供一个验证字,并从服务器接收一个访问远端文件的权限, 或一套配置

24、选项传给马上就要引导入的操作系统。 我的(服务器)IP地址填入siaddr字段。设置op字段为BOOTREPLY(引导应答)。 UDP目的端口设置成BOOTP客户端。如果客户端地址ciaddr非0,把包发送到那里; 否则如果网关地址giaddr非0,设置UDP目的端口为BOOTP服务器并把包发送到giaddr。 否则客户端在我们的一个网络中但它还不知道自己的IP地址,使用在上面蛋章节中描述的方法来传送它到客户端。 如果使用蛋并且我们在主机上有许多接口,使用yiaddr(你的IP地址)字段指出发送包到哪个网络(网络/接口)。 UDP校验和6.4 服务器/网关接收BOOTREPLY(引导应答) U

25、DP校验和 如果yiaddr (你的客户端的IP地址)指向我们的一个网络,使用上述蛋方法来将它转发到客户端。 确认将它传送到BOOTP客户端UDP目的端口。6.5 客户端接收 不要忘记为我自己的IP地址(如果我知道)处理ARP请求。UDP校验和 客户端应该丢弃以下进入的包:不是定位到引导端口的IP/UDP;不是BOOTREPLY(引导应答); 不匹配我的IP地址(如果我知道)或我的硬件地址;不匹配我的事务ID。 否则我们就收到一个成功的应答。如果我以前不知道的话,yiaddr包含我的IP地址。 file是TFTP读请求的文件名。服务器地址在siaddr中。如果giaddr(网关地址)非0, 那

26、么包应该先转发到那里,然后到达服务器。7 通过网关引导 这部分协议是可选的并要求许多网关和服务器配合的额外的代码,但它允许跨越网关引导。 这主要在网关是无盘机器时有用。 带盘网关(例如,一个做为网关的UNIX机器)可能运行它们自己的BOOTP/TFTP服务器。 侦听BOOTREQUEST(引导请求)广播的网关可能确定转发还是适当地再广播这些请求。 例如,做为配置表格的一部分,网关可以有一个接收任意BOOTREQUEST(引导请求)广播的其它网络或主机的列表。 即使考虑有一个hops字段,简单全部再广播请求仍是一个差的方法,因为广播循环几乎肯定会发生。 转发可以立即开始,或等secs(客户端尝试

27、的秒数)字段超过某个阀值。 如果一个网关确定转发请求,它应该查看giaddr (网关IP地址)字段。 如果是0,它就在这个字段中加入自己的IP地址(在接收的网络中)。 也可以使用hops字段来可选控制包可以转发多远。每次转发应该增加跳数。 例如,如果跳数超过3,包应该被丢弃。 UDP校验和 这里我们推荐在网关中增加这个特殊的转发功能。 但不总是这样子的。 在网上存在一些BOOTP转发代理引导客户端,这些代理可以适当地转发。 这样这些服务可以和网关在一起,也可以不在一起。 当转发代理不和网关在一起时,代理可以通过在接收的引导请求中giaddr字段加上接口的广播地址节省一些工作。 这样应答就可以使

28、用普通的网关来转发,而不包含转发代理。 当然劣势是你失去了使用蛋非广播方式来发送应答的能力,导致在客户端网上的每个主机的额外的花费。8 样例BOOTP服务器数据库 做为一个建议,我们提供一个BOOTP服务器查询可以使用的样例文本文件数据库。 数据库有两个节,使用第一列使用一个百分符的行做为定界符。 第一个节包含一个默认目录,和从通用名称到目录/路径的映射。 这个节中第一个通用名称是当引用请求包含空file字符串是你使用的默认文件。 第二节映射硬件地址类型/地址到IP地址。可选的,你可以使用一个特定IP地址的通用名称来忽略默认通用名称。 一个后缀项目也是可选的;如果提供,可以访问任意客户端特定的

29、通用名称对应的路径名称加上后缀。 如果那个文件没有找到,就尝试简单的路径名称。 这个后缀选项允许轻而易举建立整套用户通用(配置)。 下面显示通用格式;一个或多个空格或TAB来定界字段;后面的空字段被省略;空行和以#开始的行忽略。 # comment line homedirectory genericname1 pathname1 genericname2 pathname2 . % end of generic names, start of address mappings hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname s

30、uffix hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix . 这是一个特定的样例。注意硬件类型数值同Assigned Numbers RFC中ARP章节。 硬件类型和IP地址数值是十进制;硬件地址是十六进制的。 # last updated by smith /usr/boot vmunix vmunix tip ethertip watch /usr/diag/etherwatch gate gate. % end of generic names, start of address mappings hamilton 1 02.60.8c.06.34.98 36.19.0.5 burr 1 02.60.8c.34.11.78 36.44.0.12 101-gatew

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1