日志分类:中文RFC
RFC955_朝向一个处理过程应用的传输服务
介绍
本协议是一套国际标准中的一个,它用来方便开放系统的互连。这一套标准包含了达到此目的所需的服务和协议。
本协议的制定充分考虑到了开放系统互连参考模型中定义的相关层以及国际网络组织所定义的网络结构。特别要指出的是,本协议是一个网络层的协议。它允许端系统和中介系统之间交换配置和路由信息,以方便网络层的路由和中继操作。
端系统与中介系统之间在网络层的通信与中介系统之间的通信是分开考虑的。本协议专门讨论前者。如果附加一个负责中介系统之间通信的协议,网络层的功能将大大加强。但即使没有这个附加的协议,本协议也是非常有用的。
ES-IS协议提供了解决以下问题的方法:
1、当一个端系统并非直接连接在另一个端系统上时,这个端系统如何发现中介系统的存在和可达性并通过它来将NPDU传送到另一个端系统。
2、由于NSAP地址并不能提供子网中的目的地址,端系统如何发现同一个子网中的另一个端系统。
3、中介系统如何发现与它直接相连的各个子网内的端系统的存在。
ES-IS协议假定以下情况的存在:
1、子网本身能够顺利地完成在本网内发送信息到子网连接点的工作。
2、子网本身不能仅依靠NSAP地址在全网范围内与目的地址通信。
注:由于以上的原因,应用层通信不能直接利用该协议提供的功能。
ES-IS协议无连接的,它被设计用来:
1、减少端系统之间通信前所需要的状态信息。
2、减少端系统上用来存放路由信息所需的内存空间。
3、降低路由算法的复杂性。
本协议的设计是和提供无连接网络服务的协议有紧密的关系的。由于路由的种类与通信的种类密切相关,所以当网络层不是使用ISO协议时,本协议可能无法提供路由需要的信息。
RFC951_引导协议(BOOTP)
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允许客户端通过使用相邻的网关从几跳外的服务器上引导。请看下面’通过网关引导’的章节。
这部分协议不需求客户端部分做特定的动作。
实现是可选的,网关和服务器需要一些额外的代码。
RFC949_FTP 未公开的独特命令
RFC948_IP 数据包通过IEEE 802.3 网络传输的两种方法
介绍
IEEE 802方案定义了ISO开放式系统互联参考模型(ISO/OSI)定义的局域网中处理物理层和数据链路层的一系列标准。几个物理层标准(802.3,802.4和802.5)[2,3,4]和一个数据链路层标准(802.2)[5]已经被制定了。IEEE物理层标准详细说明了ISO/OSI物理层和ISO/OSI数据链路层的媒体访问控制子层。802.2数据链路层标准详细说明了ISO/OSI数据链路层中逻辑链路控制子层。
802.3 标准是以第二版以太网标准[6]为基础的。以太网物理层和802.3的物理层在所有的实际应用上是兼容的,然而,以太网数据链路层和802.2/802.3数据链路层是不兼容的。
现存的许多以太网络装置使用在[7]里描述的以太网兼容标准传输ip数据报。IEEE 802.3 物理层兼容连接能够被增加到这些网络,在不违反802.3标准的情况下使用一个以太网数据链路层兼容模式传输IP数据报。二选一,使用一个802.2/803.3数据链路层兼容模式传送ip数据报。
RFC937:邮局协议( 版本 2)
提要:
这篇RFC文档提供了一种使工作站动态的从邮件服务器获取邮件的简单方法.它着重阐述了符合ARPA标准的因特网的邮件协议,并为它的进一步发展提供了建议和讨论.它是 RFC 918的更新.你可以自由传播这个文档.
引言
邮局协议(版本2)的目的是为了让用户的工作站从邮件服务器获取邮件.它也应该允许邮件从工作站通过简单邮件传递协议(SMTP)发送到邮件服务器.更多内容请参考POP2 821[1]和POP2 822[2].
这个协议假定已经存在了一个可靠的数据流,比如由TCP协议或其它协议提供的数据流.
如果是TCP协议,则POP2协议服务器从109端口进行监听.
RFC932:子网地址分配方案
摘要
最近有几份RFS文档讨论了在Internet地址分配方案中对“子网”结构的需要,并提出了子网地址分配和路由策略。特别是Jeff Mogul在RFC917《Internet子网》中,描述了一个地址分配方案,将主机地址部分的开始一些位用来标识子网。这个方案的缺点是需要修改现有主机软件的实现。虽然改动很简单,但所有的主机都需要更新。(请参阅Jeff Mogul RFC917中解决这个问题的不同方法的描述)。
本文档提出另一个子网的地址分配方案。本方案在大多数情况下不需要修改主机软件。其缺点是一个网络中的子网数量受到限制,而且需要修改所有的网关。
RFC930:Telnet终端类型选项
本备忘录的状态
本RFC规范了一个ARPA Internet community上的标准。在ARPA Internet上的所有主机应当采用和实现这个标准。本文的发布不受任何限制。
本标准是对RFC884的更新。唯一的变化是定义了TERMINAL-TYPE IS子谈判只能在对TERMINAL-TYPE SEND子谈判作出回应时送出。
RFC925:多局域网地址解决
介绍
将一组局域网(LAN)作为单个互联网处理的问题已经引起广泛关注和兴趣。在同一地点内的局域网都给与一个截然不盒子同的网络号,这是不妥当的。令人满意的做法是,对人员,网关和外部主机而言,地点内各局域网间的细节是隐蔽的。面临的问题是最好怎么做,甚至上究竟怎么做。一个建议是使用“显式子网[1]”。显式子网方案是一个把互联网用于管理多个网络的机制应用到在一个网络内的各局域网的管理问题上的一个叫法。请注意,我强烈推荐另一个方法:使用一个由多局域网地址解析协议扩展所支持的“透明子网”。
RFC917:因特网子网
摘要
本文档讨论因特网中“子网”的效用。“子网”是整个因特网中的一部分。由于管理和技术的原因,许多机构选择把一个网络分成几个子网,而不是单纯的使用一系列的因特网地址。
本文档提出使用子网的程序和过程,并讨论解决由此而产生的问题的方法,特别是路由问题。