Tcp/ip协议-Ip-网络协议分析
摘要
这一改进有效地拓展了核心系统的概念使其涵盖多个自治系统社区——称之为自治联邦，现有的实现无需修改就可以与增强的实现协同工作。与一般的自治系统之间相比，自治联邦维持了更高的互信度，包括避免成员系统之间出现路由循环的合理保护，但是允许放宽当前EGP模型的路由限制。
改进包括EGP更新消息的“跳数”或者距离字段，当前的EGP模型没有纳入对这一字段的解释。每个自治联邦对这个字段都给出了特定的解释以支持最多三层的路由：一是在自治系统内，二是在自制联邦内，三是在联邦全体内，其中第三层是可选的。
点击下载：[PDF]RFC975_自治联邦_中文版
简介
本备忘录的目的在于阐明邮寄方如何确定以给定的Internet域名为地址的消息的发送路由。其中包括关于邮寄方如何解释MX RR的讨论，MX RR用于消息路由。注意，本备忘录没有涉及邮寄方如何处理MB RR和MG RR的陈述，这两者用于邮箱名的解释。
RFC 882和RFC 883中关于邮件地址的一些设想已经发生了变化。现在一般可以认为如果消息的地址是一个信箱——比如LOKI.BBN.COM，只要打开一个对LOKI.BBN.COM的SMTP连接向前发就可以了。这种系统不适用于某些特定的情况，比如没有直接接入Internet的特定的UUCP和CSNET主机，不过这些主机可以在配置文件中作为特殊情况处理（比如大部分邮寄者都设定把发送给CSNET的邮件自动转发给CSNET-RELAY.ARPA）。
在域名系统中不能简单地打开对LOKI.BBN.COM的连接，而必须向域名系统询问发往LOKI.BBN.COM的消息如何递送。域名系统可能会指导邮寄者把消息传递到一个完全不同的主机，譬如SH.CS.NET。或者在更加复杂的情形中，邮寄者可能得知它有一个到LOKI.BBN.COM的路径可以选择。本备忘录主要讲述在这种更加复杂的情况下邮寄者如何工作的一些指导原则。
希望读者已经熟悉了RFC 882、RFC 883和它们的更新版本（如RFC973）。
本协议是一套国际标准中的一个，它用来方便开放系统的互连。这一套标准包含了达到此目的所需的服务和协议。
本协议的制定充分考虑到了开放系统互连参考模型中定义的相关层以及国际网络组织所定义的网络结构。特别要指出的是，本协议是一个网络层的协议。它允许端系统和中介系统之间交换配置和路由信息，以方便网络层的路由和中继操作。
端系统与中介系统之间在网络层的通信与中介系统之间的通信是分开考虑的。本协议专门讨论前者。如果附加一个负责中介系统之间通信的协议，网络层的功能将大大加强。但即使没有这个附加的协议，本协议也是非常有用的。
ES-IS协议提供了解决以下问题的方法：
1、当一个端系统并非直接连接在另一个端系统上时，这个端系统如何发现中介系统的存在和可达性并通过它来将NPDU传送到另一个端系统。
2、由于NSAP地址并不能提供子网中的目的地址，端系统如何发现同一个子网中的另一个端系统。
3、中介系统如何发现与它直接相连的各个子网内的端系统的存在。
ES-IS协议假定以下情况的存在：
1、子网本身能够顺利地完成在本网内发送信息到子网连接点的工作。
2、子网本身不能仅依靠NSAP地址在全网范围内与目的地址通信。
注：由于以上的原因，应用层通信不能直接利用该协议提供的功能。
ES-IS协议无连接的，它被设计用来：
1、减少端系统之间通信前所需要的状态信息。
2、减少端系统上用来存放路由信息所需的内存空间。
3、降低路由算法的复杂性。
本协议的设计是和提供无连接网络服务的协议有紧密的关系的。由于路由的种类与通信的种类密切相关，所以当网络层不是使用ISO协议时，本协议可能无法提供路由需要的信息。
本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允许客户端通过使用相邻的网关从几跳外的服务器上引导。请看下面’通过网关引导’的章节。
这部分协议不需求客户端部分做特定的动作。
实现是可选的，网关和服务器需要一些额外的代码。
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数据报。
提要:
这篇RFC文档提供了一种使工作站动态的从邮件服务器获取邮件的简单方法.它着重阐述了符合ARPA标准的因特网的邮件协议,并为它的进一步发展提供了建议和讨论.它是 RFC 918的更新.你可以自由传播这个文档.
引言
邮局协议(版本2)的目的是为了让用户的工作站从邮件服务器获取邮件.它也应该允许邮件从工作站通过简单邮件传递协议(SMTP)发送到邮件服务器.更多内容请参考POP2 821[1]和POP2 822[2].
这个协议假定已经存在了一个可靠的数据流,比如由TCP协议或其它协议提供的数据流.
如果是TCP协议,则POP2协议服务器从109端口进行监听.
摘要
最近有几份RFS文档讨论了在Internet地址分配方案中对“子网”结构的需要，并提出了子网地址分配和路由策略。特别是Jeff Mogul在RFC917《Internet子网》中，描述了一个地址分配方案，将主机地址部分的开始一些位用来标识子网。这个方案的缺点是需要修改现有主机软件的实现。虽然改动很简单，但所有的主机都需要更新。（请参阅Jeff Mogul RFC917中解决这个问题的不同方法的描述）。
本文档提出另一个子网的地址分配方案。本方案在大多数情况下不需要修改主机软件。其缺点是一个网络中的子网数量受到限制，而且需要修改所有的网关。
本备忘录的状态
本RFC规范了一个ARPA Internet community上的标准。在ARPA Internet上的所有主机应当采用和实现这个标准。本文的发布不受任何限制。
本标准是对RFC884的更新。唯一的变化是定义了TERMINAL-TYPE IS子谈判只能在对TERMINAL-TYPE SEND子谈判作出回应时送出。
