Skip to main content

1. 简介 (INTRODUCTION)

本文档是定义和讨论互联网协议套件主机系统实现要求的一对文档之一。本RFC涵盖通信协议层：链路层、IP层和传输层。其配套RFC"互联网主机要求 -- 应用和支持"[INTRO:1]涵盖应用层协议。本文档还应与"互联网网关要求"[INTRO:2]结合阅读。

这些文档旨在为互联网通信软件的供应商、实现者和用户提供指导。它们代表了由互联网研究和供应商社区成员贡献的大量技术经验和智慧的共识。

本RFC列举了连接到互联网的主机必须使用的标准协议，并通过引用包含了描述这些协议当前规范的RFC和其他文档。它纠正了参考文档中的错误，并为实现者添加了额外的讨论和指导。

对于每个协议，本文档还包含一组明确的要求、建议和选项。读者必须理解，本文档中的要求列表本身是不完整的；互联网主机的完整要求集主要在标准协议规范文档中定义，本RFC中包含的更正、修订和补充内容对其进行了补充。

善意实现的协议在仔细阅读RFC并与互联网技术社区进行一些互动，并遵循良好的通信软件工程实践的情况下产生，应该仅在很小程度上与本文档的要求不同。因此，在许多情况下，本RFC中的"要求"已在标准协议文档中陈述或隐含，因此它们在此处的包含在某种意义上是冗余的。然而，它们被包括在内是因为过去的某些实现做出了错误的选择，导致了互操作性、性能和/或健壮性问题。

本文档包括对许多要求和建议的讨论和解释。简单的要求列表是危险的，因为：

  • 某些必需的功能比其他功能更重要，某些功能是可选的。
  • 可能存在正当理由，使得为受限环境设计的特定供应商产品选择使用不同的规范。

然而，必须遵循本文档的规范，以实现在互联网系统的多样性和复杂性中实现任意主机互操作的总体目标。尽管大多数当前实现在各个方面都未能满足这些要求，有些是轻微的，有些是重大的，但本规范是我们需要前进的理想目标。

这些要求基于当前的互联网架构级别。本文档将根据需要进行更新，以提供额外的澄清或包含规范仍在演进的领域的额外信息。

本引言部分首先简要概述与主机相关的互联网架构，然后向主机软件供应商提供一些一般建议。最后，提供了一些阅读文档其余部分的指导和一些术语。

1.1 互联网架构 (The Internet Architecture)​

关于互联网架构和支持协议套件的一般背景和讨论可以在DDN协议手册[INTRO:3]中找到；有关背景，请参见例如[INTRO:9]、[INTRO:10]和[INTRO:11]。参考文献[INTRO:5]描述了获取互联网协议文档的程序，而[INTRO:6]包含互联网协议内分配的编号列表。

1.1.1 互联网主机 (Internet Hosts)​

主机计算机，或简称"主机"，是通信服务的最终消费者。主机通常代表用户执行应用程序，使用网络和/或互联网通信服务来支持此功能。互联网主机对应于OSI协议套件[INTRO:13]中使用的"终端系统"概念。

互联网通信系统由使用互联网协议支持主机计算机之间通信的互连分组网络组成。这些网络使用称为"网关"或互联网社区所称的"IP路由器"以及OSI世界[INTRO:13]所称的"中间系统"的分组交换计算机互连。RFC"互联网网关要求"[INTRO:2]包含互联网网关的官方规范。该RFC与本文档及其配套文档[INTRO:1]一起定义了当前实现互联网架构的规则。

互联网主机涵盖了广泛的大小、速度和功能范围。它们的大小范围从小型微处理器到工作站、大型机和超级计算机。在功能上，它们的范围从单一用途主机（如终端服务器）到支持各种在线网络服务的全功能主机，通常包括远程登录、文件传输和电子邮件。

如果主机有多个接口连接到相同或不同的网络，则通常称为多宿主主机。参见第1.1.3节中的"术语"。

1.1.2 架构假设 (Architectural Assumptions)​

当前的互联网架构基于一组关于通信系统的假设。与主机最相关的假设如下：

(a) 互联网是网络的网络。

每个主机直接连接到某些特定网络；它与互联网的连接只是概念性的。同一网络上的两个主机使用相同的协议集相互通信，就像它们用于与远程网络上的主机通信一样。

(b) 网关不保留连接状态信息。

为了提高通信系统的健壮性，网关被设计为无状态的，独立转发每个IP数据报，而不依赖于其他数据报。因此，尽管中间网关和网络发生故障，仍可以利用冗余路径提供健壮的服务。

端到端流控制和可靠性所需的所有状态信息都在主机中实现，在传输层或应用程序中。因此，所有连接控制信息都与通信的端点位于同一位置，因此只有在端点失败时才会丢失。

(c) 路由复杂性应该在网关中。

路由是一个复杂而困难的问题，应该由网关执行，而不是主机。一个重要的目标是使主机软件免受互联网路由架构不可避免演进引起的变化的影响。

(d) 系统必须容忍广泛的网络变化。

互联网设计的基本目标是容忍广泛的网络特性范围 -- 例如，带宽、延迟、数据包丢失、数据包重新排序和最大数据包大小。另一个目标是对单个网络、网关和主机的故障具有健壮性，使用仍然可用的任何带宽。最后，目标是实现完全的"开放系统互连"：互联网主机必须能够在不同的互联网路径上与任何其他互联网主机进行健壮且有效的互操作。

有时主机实现者为不太雄心勃勃的目标进行设计。例如，LAN环境通常比互联网整体更温和；LAN具有低数据包丢失和延迟，并且不会重新排序数据包。一些供应商已经推出了适合简单LAN环境但对一般互操作性工作不佳的主机实现。供应商将此类产品辩解为在受限的LAN市场中具有经济性。然而，隔离的LAN很少长时间保持隔离；它们很快就会通过网关相互连接，连接到组织范围的互联网，并最终连接到全球互联网系统。最终，客户和供应商都不会受到不完整或不合格的互联网主机软件的服务。

本文档中阐述的要求是为全功能互联网主机设计的，能够在任意互联网路径上实现完全互操作。

1.1.3 互联网协议套件 (Internet Protocol Suite)​

要使用互联网系统进行通信，主机必须实现构成互联网协议套件的分层协议集。主机通常必须至少从每一层实现一个协议。

互联网架构中使用的协议层如下[INTRO:4]：

  • 应用层 (Application Layer)

应用层是互联网协议套件的顶层。互联网套件不进一步细分应用层，尽管一些互联网应用层协议确实包含一些内部子分层。互联网套件的应用层本质上结合了OSI参考模型的顶部两层 -- 表示层和应用层 -- 的功能。

我们区分两类应用层协议：直接向用户提供服务的用户协议，以及提供通用系统功能的支持协议。用户和支持协议的要求将在配套RFC [INTRO:1]中找到。

最常见的互联网用户协议是：

  • Telnet（远程登录）
  • FTP（文件传输）
  • SMTP（电子邮件传递）

还有许多其他标准化的用户协议[INTRO:4]和许多私有用户协议。

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

  • 传输层 (Transport Layer)

传输层为应用程序提供端到端通信服务。目前有两个主要的传输层协议：

  • 传输控制协议(TCP)
  • 用户数据报协议(UDP)

TCP是一种可靠的面向连接的传输服务，提供端到端可靠性、重新排序和流控制。UDP是一种无连接（"数据报"）传输服务。

研究社区已经开发了其他传输协议，官方互联网传输协议集可能会在未来扩展。

传输层协议在第4章中讨论。

  • 互联网层 (Internet Layer)

所有互联网传输协议都使用互联网协议(IP)将数据从源主机传送到目标主机。IP是一种无连接或数据报互联网服务，不提供端到端传递保证。因此，IP数据报可能到达目标主机时损坏、重复、无序或根本不到达。当需要可靠传递服务时，IP之上的层负责提供。IP协议包括寻址、服务类型规范、分片和重组以及安全信息的规定。

IP协议的数据报或无连接性质是互联网架构的基本和特征性特征。互联网IP是OSI无连接网络协议[INTRO:12]的模型。

ICMP是一种被认为是IP组成部分的控制协议，尽管它在架构上分层于IP之上，即它使用IP端到端传送其数据，就像TCP或UDP等传输协议一样。ICMP提供错误报告、拥塞报告和第一跳网关重定向。

IGMP是用于为IP组播建立动态主机组的互联网层协议。

互联网层协议IP、ICMP和IGMP在第3章中讨论。

  • 链路层 (Link Layer)

要在其直接连接的网络上进行通信，主机必须实现用于与该网络接口的通信协议。我们称之为链路层或媒体访问层协议。

有各种各样的链路层协议，对应于许多不同类型的网络。参见第2章。

1.1.4 嵌入式网关代码 (Embedded Gateway Code)​

一些互联网主机软件包括嵌入式网关功能，因此这些主机可以像网关一样转发数据包，同时仍然执行主机的应用层功能。

此类双重用途系统必须遵循网关要求RFC [INTRO:2]中关于其网关功能的要求，并且必须遵循本文档中关于其主机功能的要求。在所有重叠的情况下，两个规范应该一致。

互联网社区对嵌入式网关功能有不同的意见。主要论点如下：

  • 支持方：在网络非正式的本地网络环境或隔离的互联网中，使用现有主机系统作为网关可能很方便且经济。

还有一个关于嵌入式网关功能的架构论点：多宿主比最初预见的要普遍得多，多宿主迫使主机做出路由决策，就好像它是一个网关一样。如果多宿主主机包含嵌入式网关，它将拥有完整的路由知识，因此将能够做出更优化的路由决策。

  • 反对方：网关算法和协议仍在变化，并且随着互联网系统的增长，它们将继续变化。尝试在主机IP层中包含通用网关功能将迫使主机系统维护人员跟踪这些（更频繁的）变化。此外，更大的网关实现池将使协调变化更加困难。最后，网关IP层的复杂性略高于主机，使实现和操作任务更加复杂。

此外，某些主机的操作方式不适合提供稳定和健壮的网关服务。

这两种观点都有相当大的优点。可以得出一个结论：主机管理员必须有意识地控制给定主机是否充当网关。有关详细要求，请参见第3.1节。

1.2 一般考虑事项 (General Considerations)​

互联网主机软件供应商已经学到了两个重要的教训，新供应商应该认真考虑。

1.2.1 互联网的持续演进 (Continuing Internet Evolution)​

互联网的巨大增长揭示了大型基于数据报的分组通信系统中的管理和扩展问题。这些问题正在得到解决，因此本文档中描述的规范将继续演进。这些变化将被仔细规划和控制，因为供应商和负责网络运营的组织广泛参与了这一规划。

开发、演进和修订是当今计算机网络协议的特征，这种情况将持续数年。为互联网协议套件（或任何其他协议套件！）开发计算机通信软件然后未能维护和更新该软件以适应不断变化的规范的供应商将留下一连串不满意的客户。互联网是一个大型通信网络，用户通过它保持持续联系。经验表明，关于供应商软件缺陷的知识会迅速在互联网技术社区中传播。

1.2.2 健壮性原则 (Robustness Principle)​

在协议的每一层，都有一个一般规则，其应用可以在健壮性和互操作性方面带来巨大好处[IP:1]：

"在接受时要宽容，在发送时要保守"

应该编写软件来处理每一个可以想象的错误，无论多么不可能；迟早会有一个具有该特定错误和属性组合的数据包进来，除非软件准备好了，否则可能会导致混乱。一般来说，最好假设网络中充满了恶意实体，它们会发送旨在产生最坏可能效果的数据包。这种假设将导致适当的保护设计，尽管互联网中最严重的问题是由低概率事件触发的未预见机制引起的；单纯的人类恶意永远不会采取如此曲折的方式！

必须将适应变化的能力设计到互联网主机软件的所有级别中。作为一个简单的例子，考虑包含特定头字段值枚举的协议规范 -- 例如，类型字段、端口号或错误代码；必须假定此枚举是不完整的。因此，如果协议规范定义了四个可能的错误代码，则软件不得在出现第五个代码时中断。未定义的代码可能会被记录（见下文），但不得导致故障。

该原则的第二部分几乎同样重要：其他主机上的软件可能包含缺陷，使得利用合法但模糊的协议功能变得不明智。偏离明显和简单的做法是不明智的，以免在其他地方产生不良影响。这的一个推论是"当心行为不端的主机"；主机软件应该准备好不仅在其他行为不端的主机中幸存下来，而且还要合作限制此类主机可能对共享通信设施造成的破坏量。

1.2.3 错误记录 (Error Logging)​

互联网包括各种各样的主机和网关系统，每个系统都实现许多协议和协议层，其中一些在其互联网协议软件中包含错误和错误特性。由于复杂性、多样性和功能分布，互联网问题的诊断通常非常困难。

如果主机实现包括用于记录错误或"奇怪"协议事件的精心设计的设施，将有助于问题诊断。重要的是在记录错误时包含尽可能多的诊断信息。特别是，记录引起错误的数据包的头通常很有用。但是，必须注意确保错误记录不会消耗过多的资源或以其他方式干扰主机的操作。

异常但无害的协议事件有溢出错误记录文件的趋势；这可以通过使用"循环"日志，或仅在诊断已知故障时启用记录来避免。过滤和计数重复的连续消息可能很有用。一种似乎很有效的策略是：(1)始终计数异常并通过管理协议使此类计数可访问（见[INTRO:1]）；(2)允许选择性地启用各种事件的记录。例如，能够"记录所有内容"或"记录主机X的所有内容"可能很有用。

请注意，不同的管理部门可能对他们希望在主机中正常启用的错误记录量有不同的政策。有些人会说，"如果它不伤害我，我不想知道它"，而其他人会希望对检测和消除协议异常采取更加警惕和积极的态度。

1.2.4 配置 (Configuration)​

如果互联网协议套件的主机实现可以完全自我配置，那将是理想的。这将允许整个套件在ROM中实现或铸造成硅，它将简化无盘工作站，并且对于疲于应付的LAN管理员以及系统供应商来说都将是一个巨大的福音。我们还没有达到这个理想；事实上，我们甚至还没有接近。

在本文档的许多地方，您会发现参数必须是可配置选项的要求。这些要求背后有几个不同的原因。在少数情况下，目前对最佳值存在不确定性或分歧，将来可能需要更新推荐值。在其他情况下，该值确实取决于外部因素 -- 例如，主机的大小及其通信负载的分布，或附近网络的速度和拓扑 -- 并且自我调整算法不可用且可能不足。在某些情况下，由于管理要求需要可配置性。

最后，需要一些配置选项来与互联网许多地方存在的协议的过时或不正确实现进行通信，这些实现在没有源代码的情况下分发。为了使正确的系统与这些有缺陷的系统共存，管理员通常必须"错误配置"正确的系统。这个问题将随着有缺陷系统的退役而逐渐自行纠正，但供应商不能忽视它。

当我们说参数必须是可配置的时，我们并不打算要求在每次引导时都从配置文件中显式读取其值。我们建议实现者为每个参数设置默认值，因此配置文件仅在特定安装中不适当的默认值需要覆盖时才必要。因此，可配置性要求是一种保证，即即使在仅二进制或基于ROM的产品中，也有可能在必要时覆盖默认值。

本文档在某些情况下要求此类默认值的特定值。当配置项控制对现有有缺陷系统的适应时，默认值的选择是一个敏感问题。如果互联网要成功收敛到完全互操作性，则内置到实现中的默认值必须实现官方协议，而不是"错误配置"以适应有缺陷的实现。虽然默认值可能因安装而异是合理的，但通常不可接受的是，所有供应商的默认值都应该迁就不正确的实现。

1.3 阅读本文档 (Reading this Document)​

1.3.1 组织 (Organization)​

本文档涵盖以下主要领域：

  • 链路层（第2节）
  • 互联网层协议（第3节）
  • 传输层协议（第4节）

1.3.2 要求 (Requirements)​

在本文档中，用于定义每个特定要求重要性的词语都大写。这些词语是：

  • 必须 (MUST)：此词或形容词"必需(REQUIRED)"表示该项是规范的绝对要求。
  • 应该 (SHOULD)：此词或形容词"推荐(RECOMMENDED)"表示在特定情况下可能存在忽略此项的有效理由，但在选择不同的方案之前，必须理解全部含义并仔细权衡情况。
  • 可以 (MAY)：此词或形容词"可选(OPTIONAL)"表示该项是真正可选的。

1.3.3 术语 (Terminology)​

本文档使用以下技术术语：

  • 段 (Segment)：段是TCP协议中端到端传输的单位。
  • 消息 (Message)：在对较低层协议的描述中，消息是传输层协议中的传输单位。
  • 数据报 (Datagram)：数据报是IP数据包。
  • 数据包 (Packet)：数据包是任何格式化的数据块。
  • 帧 (Frame)：帧是链路层数据包。
  • 连接网络 (Connected Network)：连接网络是主机接口的任何网络，无论是物理、虚拟还是逻辑上。
  • 多宿主 (Multihomed)：如果主机有多个IP地址，则称该主机为多宿主。

1.4 致谢 (Acknowledgments)​

本文档包含了互联网社区许多成员的贡献和评论。

Last updated on