RFC 1122A

本文档定义并讨论了主机系统实现IP协议簇的要求,涵盖了链路层、IP层和传输层三个通信协议层。与之相应的RFC文档“因特网主机要求--应用与支持”[INTR：1]阐述了应用层的协议，同时参阅“因特网网关要求”[INTRO：2]。

这些文档旨在为因特网通信软件的开发者、实现者及用户提供指导。这些文档凝聚了Internet研究和开发组织的相关人员的许多技术经验与智慧。

本文档列举了主机连上因特网所必须的标准协议参照了相关的RFC文档和其他文档中关于这些协议最新的描述。修正了参考文档中的一些错误并为实现者增加了额外的讨论和指导。

对于每个协议，文档中包含了详细的必须要求、推荐要求和可选要求。读者们应当明确文档中所述的必须要求并不完备，对于因特网主机完整的要求主要是在标准协议文档中定义。本RFC只是对其进行修改、修正和完善。

如果一个协议是在认真阅读了RFC的标准并与因特网技术社团有了一定的交互，同时按照软件工程要求进行良好的沟通的基础上完成的，那么这个协议于本文档的要求应该基本吻合。对于协议较好的实现是同时，本RFC中所述的“要求”已经在标准文档中阐述过了，因此某种程度上说就是多余的了。但这些要求在本文档中的出现是因为在过去的实现中由一些错误的血则，引起了交互性、可用性和/或健壮性的问题。 本文档包括了许多的要求和推荐项。简单地列出所有的要求是很危险的，因为： 1. 有些要求比其他的更重要，而还有一部分是可选的内容。

2. 有一些产品由于设计在严格的上下文环境中因此可能选择使用一些不同的规程。

但对于面向一般需求的主机为了在交互中适应因特网的多样性和复杂性，必须要遵从本文档的规程规定。虽然在实际上有许多的实现并没有完全按照本文档所述的要求，但这些规程是理想的模式，也是我们努力的方向。

这些要求是基于现行的因特网体系结构的层次设计的。随着其他的规程的不断发展，文档所述的内容也需要更新，加以辨别或者添加新的信息。

介绍部分由与主机相关的因特网体系结构的概貌开始，并给主机软件生产商一些整体的意见。最后会有一些阅读文档的剩余部分和术语的一些指导。
1.1 因特网体系结构

因特网的体系结构和支持协议簇可参照DDN协议手册[INTRO：3]，背景

资料举例参照[INTRO：9][INTRO：10][INTRO：11]。[INTRO：5]的参考描述了获得因特网协议文档的过程；[INTRO：6]包含了IP协议分配的一系列序号。 1.1.1 Internet主机

一个主机电脑，也就是常说的“主机”是通信服务的最后客户端。主机通过网络和/或使用因特网通信服务代表用户执行应用层程序。而因特网主机就是OSI协议簇[INTRO：13]中“端系统(end-system)”的概念。

因特网通信系统由互联的网络构成，这些网络支持了通过IP协议相互通信的主机电脑。网络间的互联是通过使用分组交换的电脑即因特网社区里所说的“网关(gateway)”或“IP路由器(IProute)”，也就是OSI中的“媒介系统(intermeida system)”。RFC“因特网网关要求[INTRO：2]”包含了因特网网关的官方规程。那篇RFC、本文档和[INTRO：1]定义了现行的因特网体系结构的实现规则。

因特网主机有很多不同的大小，速度和功能。在大小上，主机的虽然可以小到工作站的微处理器大到大型机和超级计算机。在功能上，主机小到单目标主机(譬如服务器终端)大到支持许多线上网络服务，尤其是包括远程登录，文件传输和电子邮件的服务齐全的主机。

1.1.2 体系结构设想

现行的因特网体系结构是基于通信系统的设想。之中与主机相关的设想如下：

(a) 因特网是网络的联网

每个主机都与某个特定的网络直接相连，但这种连接只是概念上的。处于同一网络的两台主机只有在对远程网络的通信中采用一组相同协议的条件下才能进行通信

(b) 网关不能保存连接状态信息

为了增强通信系统的健壮性，网关旨在独立于其他数据报来转发每个IP数据报。结果，虽然中间网关和网络有可能失败，为了保证服务的健壮性可以找出其他的通路。

所有端到端的流控制和可靠性所需的状态信息是在主机传输层或应用层实现的。而所有的连接控制信息是在通信的端点产生的，故仅当端点失败时信息会丢失。

(c) 路由的复杂性由网关处理

路由是一个复杂又困难的问题必须有网关而不是主机来处理。一个重要的目标就是使主机软件能屏蔽不可避免的因特网路由体系发展带来的变化。

(d) 系统必须能够适应网络的多样性

因特网设计的根本目标是适应各种网络的情况--譬如带宽、延时、分组丢失、分组重排和最大分组大小。另一个目标是在面对使用各种不同带宽的网络、网关和主机时，可以保持健壮性。最后的目标是达到保全的“开放系统互连(OSI)”：使得每个因特网主机可以同多不同的因特网通路与其他因特网主机健壮地有效地合作。
有时主机实现者的设计目标较为模糊，比如，局域网环境显然要比整个因特网情况更好，局域网的丢包率较低，时延较少而且不进行分组重传。有些生产商在简单的局域网上较好地实现了主机系统，但在整体的互联上情况很糟糕。生产上判断一件产品是否经济可行实在有限的局域网市场上试验的。但是被隔离的局域网并不一直是孤立的，它们通过网关相互相连，连接到某个组织内的网络，最终连接到整个因特网。最后顾客和生产者都是用的是完全的标准的因特网主机软件。

本文档中指出的要求是为能完成完备的功能的因特网主机而设计的，能够通过任意的因特网通路达到完备的互用性。

1.1.3 IP协议簇

使用因特网系统进行桶金，主机必须实现由IP协议簇组成的分层协议集合。主机每层必须至少实现一个协议。 因特网体系结构中使用的隔层协议[INTRO：4]主要有： 1. 应用层

应用层是IP协议簇中的最高层。虽然有一些因特网应用层协议确实包含了一些内部的子层划分，但基于因特网的软件集并没有再把应用层再划分子层。因特网软件集中的应用层协议必须包含最高两层--表示层和应用层--根据OSI参考模型的规定。

我们将应用层协议分为两类：直接为用户提供服务的用户协议和提供系统功能的支持协议。对于用户和支持协议的要求将在相关的RFC文档中找到[INTRO：1]。

最常使用的因特网用户协议包括： a)Telnet(用于远程登录) b)FTP(用于文件传输) c)SMTP(电子邮件发送) 同时还有许多标准化的用户协议[INTRO：4]和许多私有用户协议。

支持协议用于主机的名字映射，导入和管理，包括SNMP、BOOTP、RARP和DNS(域名系统)协议。

2. 传输层

传输层为应用层提供了端到端的通信服务。现在主要有两种传输层协议：

a)传输控制协议()TCP0 b)用户数据报协议(UDP)

TCP是面向连接的传输服务提供端到端的可靠传输，重新排序和流控制。UDP是一个面向非连接的传输服务。

传输层协议将在第四章中进行讨论。 3. 网络层

所有的因特网传输层协议都使用了IP协议将数据由源主机传送至目的主机。IP指一个面向非连接的网络服务，不提供端到端的保证。
这样，IP数据报有可能在到达目的主机时就已经被破坏、重传、乱序或安全到达。IP以上的各层在需要时负责服务的可靠性。IP协议包括了寻址、服务类型、分片、重组和安全信息的规定。

IP协议的面向非连接是因特网体系结构的一项根本的典型的特征。因特网IP是OSI面向非连接的网络协议的模型[INTRO：12]。

ICMP是IP不可分割的一个控制协议，虽然在体系结构上，它位于IP层，但它像传输层协议TCP或UDP协议一样使用IP分组来携带数据。ICMP包括错误报告，拥塞报告和第一跳网关重定向。 IGMP是用于建立能够进行IP多播的动态主机组的网络层协议。 IP、ICMP、IGMP这些网络层协议将在第三章中进行讨论。 4. 链路层

主机为了在直接相连的网络中进行通信必须实现接口与网络相连的通信协议。我们称之为链路层或媒体介入层协议。

在许多不同类型的网络上有许多链路层的协议与之相适应，请参照第二章。

嵌入式网关代码

有些因特网主机软件包含了嵌入式的网关功能，那么这些主机在执行主机的应用层功能时就可以像王冠一样转发分组。

这样双目的的系统必须既按照网关要求的RFC规定[INTRO：2]又按照针对其主机功能的文档规定。在所有相交迭的情况中这两个规定必须达成一致。

对于主机中嵌入网关的功能因特网社区内有许多不同的意见。主要的争议如下：

1.优点：

在网络不太规范的独立的本地网络中，是主机具有网关的功能可能是方便又经济的。

但也有许多对于嵌入式网关功能的体系结构上的争议：多宿主的应用比早期的遇见要普遍得多而多宿主的功能uaoxiu 主机箱王冠一样做出路由选择。如果多宿主主机包含了一个嵌入式的网关，它就可以很好地进行路由并作出理想的路由选择。

2.缺点：

网关算法和协议一直不断改变并将随着因特网系统的发展而继续改变。在主机IP层中加入网关的功能的尝试将会迫使主机系统跟随着这些改变而不断更新。最后网关IP层通常比主机的更复杂，这就使得这一实现和操作更加复杂。

这两种观点都各有优点，从中可以得出一个结论：主机管理员必须对于是否使主机扮演网关的角色有明确的控制。参照3.1节的详细说明。

1.2 整体设计

因特网主机软件的生产商已经认识到的和新的生产商们必须认真考虑的有两个重要的方面。 1.2.1 Internet的可持续性发展

1.1.4
因特网爆炸性的增长揭示了管理和在给予大数据报分组通信系统中规模控制的问题。这些问题已经被提出来了，那么本文档中所描述的规程也将会有持续的发展。既然生产商和相关组织已经进行了大规模的划分，那么这些改变也将会谨慎的规划并加以控制。

发展、演化和修订是今天计算机网络协议的特点，这一情况还将持续多年。如果为IP协议簇设计的计算机通信网络软件的生产商没有随着要求的变化而进行维护和更新，那么将会有一大批很不高兴的顾客。因特网是一个巨大的通信网络而用户将不停地与之接触。经验表明某个软件的不足将很快在整个因特网社区里传开。 1.2.2 健壮性(鲁棒性)要求

每层的协议都有一个整体的规则，这一规则的应用将为健壮性和互用性带来巨大的好处[IP：1]。 “对于收到的信息要放宽要求，而对于发出的信息要严格规定。”

软件应该能共处理每一个有可能发生的错误无论其发生的可能性大小，早晚会接收到一个处于某种错误或属性的情况下的分组，那么只有软件在设计前考虑到这一点，才可以避免混乱的发生。总的说来，最好在设计时假设网络充满了旨在传送会带来最糟糕的影响的恶意的实体。基于这样的假设，虽然因特网上最严重的问题是由小概率事件引起的没有被重视机制导致的，设计出来的产品才具有可靠的保护性。但人们的第一往往不会经历如此曲折的过程。

面对改变的适应性应该是因特网主机软件各层设计的要点，举一个简单的例子，假设某个协议规定列举了某个特定的首部字段的值--比如，类型字段，断口字段或错误号。这个列举值通常不是完全的。这样，如果协议规定了四种可能的错误代码，那么这个软件不应该在第五种取值出现时就瘫痪了。这个违背定义的编号应该写入日志(见下文)但他不应该引起故障。

第二个关键原则也很重要：其他主机上的软件可能包含了一些缺陷，很不明智地使用了了一些合法但很模糊的协议特征。不使用明确的简单的部分来避免麻烦的结果是不明智的。这样做的必然结果就是“小心提防这些行为不正常的主机”，主机软件应该预先考虑到这个问题，不仅仅是不要成为行为不正常的主机，还要合作来减少此类主机对于共享的通信设备的损害。 1.2.3 错误日志

因特网有很多的主机和网关系统，每一个系统都实现了许多的协议和协议层，有些包含了漏洞了与相应的因特网协议软件不相符的部分。由于其复杂性、多样性和功能的分布性，要诊断因特网的问题经常比较困难。

如果主机在实现时包括了一个仔细设计记录错误或“奇怪的”协议时间的工具，那么对于因特网问题的解决会有所帮助。当错误被记录时应该尽可能多地记录诊断信息。尤其记录发生错误的分组的首部通常是比较有用的。但是应该注意错误日志不应该占用过多的资源，否则将影响主机的工作。
现在异常但无害的协议事件倾向于在错误日志文件上溢出，这一点可以通过使用“循环”日志来避免。这对于过滤和计算重复报文是很有用的。有一种看起来还不错的策略是：(1) 总是计算异常的数量并且可管理协议[INTRO：1]随时获取(2) 所要记录的事件应该可以进行选择。比如应该允许是记录“所有的事件”还是“记录主机X的所有事件”。

要注意不同的管理下对于主机内正常的错误记录策略是有所不同的。有时的处理方式是“如果这个信息不会伤害我，那么我不想知道”，而有时是抱着更激进的更警惕的态度来检测和屏蔽协议异常。 1.2.4 设置

如果主机在实现因特网协议时能够完全地自我配置是最理想的。这将完全在ROM完成，将简化了无盘工作站，对局域网管理员和系统生产上来时也是极大的福音。但我们还没有那么理想，事实上还远着呢。

本文档中的任何一点都有一个可配置选项的参数。这是有原因的，有时最优值仍存在着不确定性，有可能在今后需要更新使用新的推荐值。同时，还有一些值取决于全局因子--比如主机的大小，或通信载荷的分布，或临近网络的速度和拓扑结构--而自适应算法可能不可行或无效。有时可配置性是管理方面的需要。 最后有些配置选项需要与陈旧的或者不正确的协议实现相配合，这些情况在因特网的某些区域仍然存在。为了是正确的系统可以与这些有问题的系统共存，管理员常常不得不将正确的系统进行“错误配置”。这个问题将在这些有问题的系统退出使用舞台后才可以逐步改善，但这个问题生产商是不可以忽略的。 当我们说一个参数必须被配置，这并不是需要在每一次启动时都从配置文件中准确地读出。我们推荐实现者为每一个参数设立一个默认值，所以配置文件只有在那些默认值在特定的安装情况下是不合适的才要进行重载。这样的配置要求保证了在必要时可以进行重载，即使是在只支持二进制或基于ROM的产品。 本文档要求在某些情况下给默认值设定特定值。默认值的选择在配置项控制与存在的有缺陷的系统相适应时是一个敏感的问题。如果因特网成功地聚合了完整的互操作，那么这些植入实现中的默认值也必须实现官方的协议，而不是进行“误配置”以配合原来有问题的实现。我们要求生产者按照标准来选择默认值。
RFC1122-A(中文版)

最后我们提醒生产者必须为所有的配置参数提供相应的文档，包括其限制和效果。

组织

1.3 阅读文档

1.3.1

作为实现网络软件的组织原则的协议分层同样也用于稳当的组

织。在描述这些规则之，我们假定是实现严格意义上对于协议分层的反映。这些接下来的三个部分分别阐述了链路层，网络层和传输层的要求。相关的RFC[INTRO：1]包含了应用层软件的部分。这个分层组织方法是为了简洁性所选择的。 但是对于协议簇和推荐的实现方法来说，严格的分层是一个并不完美的模型。处在不同层的协议间的交互是复杂的优势是微妙的，而有些特定的功能常常需要涉及多个层次。在实现中有许多涉及选择，而其中许多需要闯脏性的“打破”严格的分层界限。每个实现这都应该仔细阅读[INTRO：7]和[INTRO：8]的参考。 本文档描述了层之间通过使用功能符号(比如例程调用)的概念服务接口，就像在TCP[TCP：！]中使用的那样。主机的实现必须支持这些调用的逻辑信息流，但宾不是需要竹子的有调用本身是咸。比如许多实现反映了传输层和IP层之间通过使用相同的数据结构来实现合作。这些数据结构并不是明确的例程调用，而是传递许多需要的信息的代理。 总的来说，每个文档中的主要部分都是从如下的子部分组成的： (1) 介绍

(2) 协议概要--逐部分考虑了协议规格文档，改正错误，陈述了可能模糊或定义不完备的要求，并且提供了进一步的说明和解释。 (3) 关键问题--讨论了协议的设计和实现问题，这些在概要里没有涉及到。 (4) 接口--讨论了对于之相邻的更高地服务接口。 (5) 概要--包括了这个部分的要求的小结。 本文档的许多独立主题标记为“讨论”或“实现”的附加说明的材料。这一材料旨在对之前的要求进行解释和说明。它也包括了一些针对将来有可能的方向或发展的建议。实现的材料包括了实现者可能考虑到的建议的方法。

概要小结部分旨在给文章提供指导和索引，但并不是很完整的。这些小结不会单独于整个RFC文档而被独立引用。
1.3.2 需求
2.在本文档中，下列用于定义每个要求的z重要性的词语将使用大写字母。

包括：

(1) "MUST"

这个词或者形容词“REQUIRED”表示这个项市规定是必须有的部分。（必须）必须）

(2) "SHOULD"

这个词或者形容词“RECOMMENDED”表示在特定的情况下如果有正当的理由可以忽略这个项，但应该充分了解其含义并且在选择一个不同的过程中要谨慎地权衡。（应该）应该）

(3) "MAY"

这个词或者形容词“OPTIONAL”编者这个乡是个完全的可选项。生产商可以选择包含这个项，因为某个特定的市场环境可能需要它或者因为它对产品有帮助，比如另一个生产者忽略了这个项。可以）（可以）

如果实现没有满足一个或多个“MUST”的协议要求，那么这个实现就是不合适的。如果一个实现满足协议所有的“MUST”和“SHOULD”要求，那么这个实现就可以叫做“无论何种情况都是合适的”。如果满足了所有的“MUST”项但不是所有的“SHOULD”项那么就称作“在一定条件下是合适的”。 1.3.3 术语 本文档使用了如下的专有名词： Segment报文段

报文段是TCP协议中的端到端的传输单元。报文段是

TCP首部和应用层数据构成。报文段封装成了IP数据报进行传输。

Message报文

在更低层的协议描述中，报文是传输层的传输单元。特别的，一个TCP报文段就是一个报文。一个报文由传输层协议首部和应用层数据组成。为了在因特网上进行端到端传输，报文必须封装在一个数据报中。

IP Datagram IP数据报

一个IP数据报是IP协议中的端到端的传输单元。IP数据报时有一个IP首部和传输层数据，比如一个IP首部和一个报文。
在网络层(第三部分)的描述中，“datagram”应该被理解成是IP数据报。

Package 分组

一个分组是通过网络层和链路层之间的接口的数据单元。包括了IP首部和数据。分组可能是完整的IP数据报或者是一个IP数据报的分片。

Frame 帧

帧是连路层协议的传输单元，包括了链路层的首部和一个分组。

Connected Network 互联网络

一个主机连接着的网络通常称作“本地网络”或这个主机的子网络。但是这些术语会引起混乱，因此我们在本文档中使用“Connected Network(互联网络)”。

Multihomed 多宿主

如果一台主机有多个IP地址我们就说这个主机是多宿主的。对于多宿主的讨论，下见3.3.4。

Physical network interface物理网络接口

物理网络接口是指连接到互联网络并拥有一个链路层地址(可能是唯一的)的物理接口。如果一台主机上有多个物理网络接口，它们可以共享链路层地址，但不同的主机在相同的物理网络中的地址必须是唯一的。

Logical [network] interface逻辑[网络]接口

我们定义了一个逻辑网络接口，作为区别于唯一的IP地址，而连接在互联网络中的逻辑通路，见3.3.4。

Specific-destination address特定目的地址

这是一个数据报的有效目的地址，即使在广播或多播时仍然有效，见3.2.1.3。

Path 路径

在某个给定的时刻，有一个特定的援助激发像一个特定的目的主机的所有IP数据报会按相同的顺序经过网关。路径之一一个方向。在一对主机间的两个方向上有多条不同的路径是正常的情况。

MTU 最大传输单元 MTU是可被传输的最大分组的大小。
frame, packet, datagram, message, 和segment在数据报中如下图所示：

A. 互联网络上的传输:

___ | LL hdr | IP hdr | (data) |

|____|____|_____|

<---------- Frame -----------------------------> <----------Packet -------------------->

B. IP分片前或IP重组后的情况:

__ | IP hdr | transport| Application Data |

|____|_hdr|__|

<-------- Datagram ------------------> <-------- Message -----------> TCP的情况:

__ | IP hdr | TCP hdr | Application Data |

|____|__|__|

<-------- Datagram ------------------> <-------- Segment -----------> 1.4 感谢

本文档集成了许多因特网协议的专家的贡献和意见，包括大学和研究实验室的代表，生产商以及政府部门。主要由IETF组织完成。

编者主要感谢下列孜孜不倦的同仁，他们为了本文档在过去的18个月中参加了许多会议，阅览了3百万字节的电子邮件，他们是：Philip Almquist, Dave

Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).

此外，下属的同仁也做出了很大的贡献：Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia

(BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology), and Mike StJohns (DCA).

以下人员也在特定的领域内作出了巨大贡献: Eric Allman

(Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen (Toronto).

我们十分感谢上述的所有人，还有那些被我们不注意间忘了加在名册中的同仁。

---------------------------------------------------------------------------------------------------------------------- 2. 链路层 2.1 介绍

所有的因特网系统，包括主机和网关，都对链路层协议有着相同的要求。这些要求在“因特网网关要求”[INTRO：2]的第三章中详细给出，本文中只是做了添补的工作。

2.2 协议概要 无 2.3 关键问题 2.3.1 追踪协议协商Trailer Protocol Negotiation

追踪协议[LINK：1] 可以封装链路层，但仅当通信双方都确认使可以用这个协议。如果系统不是对每个目的主机都动态地协商使用追踪协议，那么默认配置必须必须禁止这个协议。 必须

讨论：

追踪协议重新封装了发送给物理网络的分组的数据内容。有时候，追踪者通过减少操作系统中数据的复制量来提高高层协议的性能。高层协议并没有感觉到追踪者的作用，但收发双方的主机必须必须了解这个协议是否启用。 必须

对于追踪着不恰当的使用会导致很混乱的局面。只有大小属性明确的分组可以使用追踪者封装，而通常交换的分组只有很少一部分有这样的属性。因此，如果一个系统使用追踪者，而另一个系统没有使用，那么就会有一些分组成功到达而另一部分消失在了黑洞里的情况出现。 实现：

以太网中，用追踪者封装的分组使用远程以太网类型[LINK：1]并且追踪者协商是在ARP寻找目的系统的链路层地址时工作的。

特别地，ARP交换通常使用一般的IP协议类型完成，但主机若想使用追踪者会发送一个额外的”追踪者ARP应答”分组，比如一个ARP应答知名类型是追踪者封装协议类型，否则就是用正常的ARP应答格式。如果主机配置成使用追踪者来接收一个远端机器的追踪者ARP应答报文 ，那么主机就可以把这个远端机器加入使用追踪者的名册中，比如通过在ARP Cache中作一个标记。

想要接收追踪者封装的主机在其完成了正常的ARP报文交换后要发送追踪者ARP应答。这样，一台主机如果收到了对于其IP协议地址的ARP请求，那么它可以在正常的针对IP的 ARP应答报文后追加发送一个追踪者ARP应答报文。那么发送针对IP的ARP请求的主机在收到正常的ARP应答时还会收到一个追踪者ARP应答/这样在针对IP的ARP交换过程中，收发双方都可以应答它所收到的追踪者封装。

这种使用额外的追踪者ARP应答保温而不是发送追踪者协议类型的ARP应答的机制是为了避免ARP报文的连续交换而设计的，为了防止工作不正常的主机不按照规程或常规，使用其它ARP应答类型来应答追踪者ARP应答的情况发生。如果一个请求IP解析的ARP应答是对一个特别的请求而做出的，那么发送追踪者ARP应答来响应市可以避免以上的问题的。当收到了ARP应答，但主机地址仍然不知道的情况是存在的。追踪者ARP应答一般都是追加在一个应答ARP请求的应答包中。

2.3.2 地址解析协议--ARP 2.3.2.1 ARP缓冲区的有效期

地址解析协议(ARP)[LINK：2]的实现必须必须提供超时高速缓存记录必须

的刷新机制。如果这一机制需要一个超时值，那么配置时应该应该给出。 应该

也必须必须包括防止ARP洪水(高速地向某个相同的IP地址连续不断必须

的发送ARP请求)的机制。推荐的最大速率是每秒钟向每个目的地址发送一个ARP请求。

讨论：

ARP规程[LINK：2]建议但并不是强行规定当主机以太网地址发生变化时能够保持缓冲记录的有效性的超时机制。随着ARP代理的流行(见[INTRO：2]的2.4部分)，主机中的ARP缓冲项可能会无效的情况的大大增多，因此主机就需要了一些确认ARP-Cache有效性的机制。即使没有ARP代理，较长时间的ARP有效时间对于自动修正可能错误的ARP记录也是有帮助的。 实现： 下列四种机制可用于刷新旧的缓冲记录。 (1) 超时—即使缓冲内的记录仍在使用也要定时地更新。超时应该在”更新”(检查广播的ARP的源地址字段，忽略目的地址字段)时进行。对于ARP代理的情况，每分钟要进行一次超时检查。

(2) 单播轮询—定时地发送点到点的ARP请求来主动地轮询远程主机，并且在N次尝试后都没有收到ARP应答时删除缓冲中的记录。同样，超时值应该约为1分钟，通常N值取2。

(3) 链路层建议—如果链路层驱动检测到了一个发送问题，则刷去ARP缓冲区中的记录。

(4) 高层建议—从网络层到链路层如果有发送问题就提请一个调用。这个调用的作用是使相应的缓冲记录无效。这个调用应该类似于传输层到网络层的调用"ADVISE_DELIVPROB()"的形式(见3.4部分)并且实际上"ADVISE_DELIVPROB()"例程可能会调用链路层建议来使ARP缓冲记录无效。

对于处理ARP超时时用的方法(1)和(2)设定的时间应该应该约一分钟应该

或更短的时间。如果没有ARP代理，没有时延控制在很大的以太网上会出现高负荷的情况。因此对主机进行ARP缓冲进行超时设置是必要的。 2.3.2.2 ARP分组队列

链路层应该保留(而不是丢弃)至少一个(根据最新的研究情况来看) IP地址未解析的目的地相同的分组，并在地址已经被解析后发送这个分组。

讨论： 没有按照这个推荐会使得每次交换中第一个分组的丢失。虽然高层协议可以通过重传来处理分组丢失的情况，但是分组丢失影响了工作的性能。比如一个TCP打开请求的丢失将会导致往返时间的初始值的膨胀。像域名系统此类的基于UDP的应用程序会有更严重的影响。 2.3.3 以太网和IEEE802封装

对于以太网的IP封装在RFC894中进行了描述[LINK：4]，RFC1042[LINK：4]描述了IEEE802网络的IP封装。RFC1042 [INTRO：2]的3.4部分进行了详细的阐述。

每个因特网主机连接到10Mbps的以太网网络： 1. 必须使用RFC894的封装来发送和接收分组 必须

2. 应该能够接收RFC1042分组，并与RFC894分组混合，并且 应该3. 可以可以使用RFC1042封装来发送分组

实现了发送RFC894和RFC1042封装的因特网主机必须必须提供一个配置必须选择要发送哪一个，这个可选择的必须必须的默认值在RFC894里描述了。 必须

RFC1042的标准IP封装并没有使用IEEE为IP保留的协议ID值(K1=6)，而是使用了在拓展的 “SNAP”中指出了用以填充以太网字段的值(K1=170)。因特网系统一定不可以使用802分组中的值 (K1=6)。

将因特网地址转换成以太网或者IEEE802网络的链路层地址必须必须由地必须址转换协议(ARP)。

以太网的MTU是1500字节而802.3是1492。 讨论：

IEEE802.3的规程提供了10Mbps的以太网的操作，这样以太网和IEEE802.3帧可以在物理层混合。接收者可以通过802.3的长度字段来区分以太网和802.3的帧。这两个字节的字段与以太网帧的以太网类型字段相同。特别地，802.3的长度字段必须不大于1500，而所有的以太网类型有效值应该大于1500。

另一个兼容性问题是在链路层广播出现的。仅发送一种帧的广播可能不会被只接受另一种帧的主机接收。
对于这个部分设计的建议是在相同的网络中实现支持894和支持1042的系统间最大程度的直接合作。现今的情况是894系统占统治地位，但支持1042的系统有可能在将来普及开来，因此也要提供一个简单的转变。

应该认识到只支持894的系统并不能直接与支持1042的系统交互工作。如果两种系统类型在相同的网络中是使哟了能够两种不同的逻辑网络，那么它们只能通过IP网关来通信。进一步看，想要一台双格式的主机自动地选择发送格式是不可行的甚至是不可能的，因为在链路层上存在广播问题。

2.4 链路层与网络层的接口

IP层和链路层之间的分组接收接口必须指出接收的分组是否一个链路层广播。 讨论：

虽然IP曾并不知道链路层的地址(因为每种不同的网络媒介有不同的地址格式)，广播地址在允许广播的媒介上是一个重要的问题。参见3.2.2关于广播风暴的讨论内容。

IP层和链路层之间的分组发送接口必须必须包括一个5比特的TOS字段(见必须3.2.1.6)。

链路层一定不能一定不能仅向IP层发送一个目的地不可达的错误，因为目的地没一定不能有ARP缓存记录。
2.5 链路层要求概要

                                              |       | | | |S| |
                                              |       | | | |H| |F
                                              |       | | | |O|M|o
                                              |       | |S| |U|U|o
                                              |       | |H| |L|S|t
                                              |       |M|O| |D|T|n
                                              |       |U|U|M| | |o
                                              |       |S|L|A|N|N|t
                                              |       |T|D|Y|O|O|t

FEATURE	SECTION				T	T	e
Trailer encapsulation	2.3.1			x
Send Trailers by default without negotiation	2.3.1					x
ARP	2.3.2
Flush out-of-date ARP cache entries	2.3.2.1	x
Prevent ARP floods	2.3.2.1	x
Cache timeout configurable	2.3.2.1		x
Save at least one (latest) unresolved pkt	2.3.2.2		x
Ethernet and IEEE 802 Encapsulation	2.3.3
Host able to:	2.3.3
Send & receive RFC-894 encapsulation	2.3.3	x
Receive RFC-1042 encapsulation	2.3.3		x
Send RFC-1042 encapsulation	2.3.3			x
Then config. sw. to select, RFC-894 dflt	2.3.3	x
Send K1=6 encapsulation	2.3.3					x
Use ARP on Ethernet and IEEE 802 nets	2.3.3	x
Link layer report b'casts to IP layer	2.4	x
IP layer pass TOS to link layer	2.4	x
No ARP cache entry treated as Dest. Unreach.	2.4					x