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)
主机计算机，或简称为 "主机 (host)"，是通信服务的最终消费者。主机通常代表用户执行应用程序，并借助网络和/或互联网通信服务来支持该功能。互联网主机对应于 OSI 协议族 [INTRO:13] 中使用的 "端系统 (End-System)" 概念。
一个互联网通信系统由互联的分组网络组成，使用互联网协议支持主机计算机之间的通信。这些网络使用被称为 "网关 (gateways)" 或 "IP 路由器 (IP routers)"（互联网社区称谓）、"中间系统 (Intermediate Systems)"（OSI 世界称谓）[INTRO:13] 的分组交换计算机互联。RFC "互联网网关要求" [INTRO:2] 包含了互联网网关的官方规范。该 RFC 与本文件及其姊妹篇 [INTRO:1] 一道，定义了当前互联网架构实现的规则。
互联网主机在规模、速度和功能上跨度很大。其规模从微型处理器到工作站，再到大型机和超级计算机。在功能上，它们从单一用途主机（如终端服务器）到支持多种在线网络服务的全服务主机，通常包括远程登录、文件传输和电子邮件。
如果一台主机拥有到同一网络或不同网络的多个接口，通常称其为多宿主 (multihomed)。参见关于多宿主的第 3.3.4 节。
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 之上，即它像 TCP 或 UDP 这类传输协议一样使用 IP 来端到端承载其数据。ICMP 提供错误报告、拥塞报告以及第一跳网关重定向。
IGMP 是一种互联网层协议，用于为 IP 多播建立动态主机组。
互联网层协议 IP、ICMP 和 IGMP 在第 3 章讨论。
链路层 (Link Layer)
为了在其直接连接的网络上进行通信，主机必须实现用于连接该网络的通信协议。我们称之为链路层或媒体访问层协议。
存在多种不同的链路层协议，对应于许多不同类型的网络。参见第 2 章。
1.1.4 嵌入式网关代码 (Embedded Gateway Code)
某些互联网主机软件包含嵌入式网关功能，使得这些主机能够像网关一样转发分组，同时仍执行主机的应用层功能。
此类双用途系统在其网关功能方面必须遵循网关要求 RFC [INTRO:2]，并在其主机功能方面必须遵循本文件。在所有重叠的情况下，两份规范应当保持一致。
互联网社区对嵌入式网关功能存在不同意见。主要论点如下：
支持 (Pro)： 在联网非正式的局域网环境，或孤立的互联网中，使用现有的主机系统作为网关可能既方便又经济。
还有一个支持嵌入式网关功能的架构性论点：多宿主比最初预见的要普遍得多，而多宿主迫使主机像网关一样做出路由决策。如果多宿主主机包含嵌入式网关，它将拥有完整的路由知识，从而能够做出更优的路由决策。
反对 (Con)： 网关算法与协议仍在变化，并且随着互联网系统变得更大，它们将继续变化。试图在主机 IP 层中包含一个通用网关功能，将迫使主机系统维护者跟踪这些（更频繁的）变化。此外，更大的网关实现池将使协调变更更加困难。最后，网关 IP 层的复杂性略高于主机，使得实现与运维任务更为复杂。
此外，某些主机的运行风格并不适合提供稳定而稳健的网关服务。
这两种观点都有相当的道理。可以得出的一个结论是：主机管理员必须对给定主机是否充当网关拥有有意识的控制权。详细要求见第 3.1 节。
1.2 一般性考虑 (General Considerations)
互联网主机软件供应商已经吸取了两个重要教训，新的供应商应当认真考虑。
1.2.1 持续的互联网演进 (Continuing Internet Evolution)
互联网的巨大增长暴露了一个大型基于数据报的分组通信系统在管理与扩展方面的问题。这些问题正在被解决，因此本文档所描述的规范将持续演进。这些变化将被谨慎地计划与控制，因为供应商以及负责网络运维的组织广泛参与了这一规划。
开发、演进与修订是当今计算机网络协议的特征，这种情况将持续若干年。一个为互联网协议族（或任何其他协议族！）开发计算机通信软件、随后却未能针对不断变化的规范维护与更新该软件的供应商，将会留下一连串不满意的客户。互联网是一个大型通信网络，用户之间通过它保持持续联系。经验表明，关于供应商软件缺陷的知识会迅速在互联网技术社区中传播。
1.2.2 健壮性原则 (Robustness Principle)
在协议的每一层，都有一条通用规则，其应用可为健壮性与互操作性带来巨大好处 [IP:1]：
"在你接受的方面要宽容，在你发送的方面要保守 (Be liberal in what you accept, and conservative in what you send)"
软件应当被编写成能处理任何可设想的错误，无论其多么不可能发生；迟早会有一个分组带着那种特定的错误与属性组合到来，除非软件有所准备，否则混乱可能接踵而至。一般而言，最好假设网络中充满了恶意实体，它们会发送旨在产生最坏影响的分组。这一假设将引导出恰当的保护性设计，尽管互联网中最严重的问题是由低概率事件触发的未曾设想的机制引起的；单纯的人为恶意绝不会采取如此迂回的路线！
对所有级别的互联网主机软件都必须设计对变化的适应性。举个简单的例子，考虑一个协议规范，其中包含某个特定头部字段的取值枚举 —— 例如类型字段、端口号或错误码；必须假设该枚举是不完整的。因此，如果协议规范定义了四种可能的错误码，当第五种码出现时，软件绝不可崩溃。未定义的码可能被记录（见下文），但它不得导致故障。
该原则的第二部分几乎同样重要：其他主机上的软件可能包含缺陷，使得利用合法但冷僻的协议特性成为不明智之举。偏离明显而简单的事物是危险的，以免造成别处的不良影响。其推论是 "警惕行为不端的主机"；主机软件不仅应当做好准备在其它行为不端的主机面前存活下来，还应当协作以限制此类主机对共享通信设施造成的破坏程度。
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)
协议分层通常被用作实现网络软件的组织原则，也被用来组织本文档。在描述规则时，我们假设实现确实严格地映射协议的分层。因此，以下三个主要章节分别规定了链路层、互联网层和传输层的要求。姊妹篇 RFC [INTRO:1] 涵盖应用层软件。选择这种分层组织是为了简单与清晰。
然而，严格的分层对于协议族和推荐的实现方法而言都是一个不完美的模型。不同层的协议以复杂且有时微妙的方式交互，特定功能常常涉及多个层。实现中存在许多设计选择，其中许多涉及创造性地 "打破" 严格分层。我们敦促每位实现者阅读参考文献 [INTRO:7] 与 [INTRO:8]。
本文档使用一种函数式（"过程调用"）记号来描述层之间的概念服务接口，类似于 TCP 规范 [TCP:1] 中使用的记号。主机实现必须支持这些调用所隐含的逻辑信息流，但不必字面地实现调用本身。例如，许多实现通过让传输层与 IP 层共享公共数据结构来反映二者之间的耦合。于是，这些数据结构而非显式的过程调用，成为传递许多所需信息的媒介。
一般而言，本文档的每个主要章节都按以下小节组织：
- 引言 (Introduction)
- 协议逐步分析 (Protocol Walk-Through) —— 逐节考察协议规范文档，更正错误，陈述可能模糊或定义不清的要求，并提供进一步的澄清或解释。
- 具体问题 (Specific Issues) —— 讨论未包含在逐步分析中的协议设计与实现问题。
- 接口 (Interfaces) —— 讨论到下一更高层的服务接口。
- 摘要 (Summary) —— 包含本节要求的摘要。
在本文档的许多单独主题下，有标注为 "DISCUSSION" 或 "IMPLEMENTATION" 的括注材料。这些材料的目的是对前面的要求文本进行澄清与解释。它还包括一些关于可能的未来方向或发展的建议。实现材料包含实现者可能想要考虑的建议方法。
摘要小节旨在作为对正文的指南与索引，但必然简略且不完整。摘要绝不应脱离完整的 RFC 单独使用或被引用。
1.3.2 要求 (Requirements)
在本文档中，用于定义每一项特定要求的重要性的词语采用大写。这些词语是：
"MUST" (必须)
该词或形容词 "REQUIRED" 表示该项是规范的绝对要求。
"SHOULD" (应该)
该词或形容词 "RECOMMENDED" 表示在特定环境下可能存在忽略该项的正当理由，但在选择不同做法前，必须理解其全部含义并仔细权衡。
"MAY" (可以)
该词或形容词 "OPTIONAL" 表示该项的确是可选的。例如，一个厂商可能因为特定市场需要或因为能增强产品而选择包含该项；另一个厂商则可以省略同一项。
如果一个实现未能满足其所实现协议的一项或多项 MUST 要求，则该实现不符合规范。一个满足其协议的所有 MUST 要求和所有 SHOULD 要求的实现被称为 "无条件符合 (unconditionally compliant)"；一个满足所有 MUST 要求但不满足所有 SHOULD 要求的实现被称为 "有条件符合 (conditionally compliant)"。
1.3.3 术语 (Terminology)
本文档使用以下技术术语：
段 (Segment)
段是 TCP 协议中端到端传输的单位。一个段由 TCP 头部后跟应用数据组成。一个段通过封装在 IP 数据报内部传输。
消息 (Message)
在较低层协议的描述中，消息是传输层协议中的传输单位。特别地，一个 TCP 段就是一个消息。一个消息由一个传输协议头部后跟应用协议数据组成。要通过互联网端到端传输，消息必须封装在数据报内部。
IP 数据报 (IP Datagram)
IP 数据报是 IP 协议中端到端传输的单位。一个 IP 数据报由一个 IP 头部后跟传输层数据组成，即由一个 IP 头部后跟一个消息组成。
在互联网层（第 3 节）的描述中，未加限定的术语 "数据报 (datagram)" 应理解为指一个 IP 数据报。
分组 (Packet)
分组是在互联网层与链路层之间跨接口传递的数据单位。它包含一个 IP 头部和数据。一个分组可以是一个完整的 IP 数据报，或一个 IP 数据报的分片。
帧 (Frame)
帧是链路层协议中的传输单位，由一个链路层头部后跟一个分组组成。
连接的网络 (Connected Network)
主机所接口到的网络通常被称为相对于该主机的 "本地网络 (local network)" 或 "子网 (subnetwork)"。然而，这些术语可能引起混淆，因此我们在本文档中使用术语 "连接的网络 (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
最大传输单元，即可以传输的最大分组的大小。
术语帧、分组、数据报、消息和段由以下示意图说明：
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 致谢 (Acknowledgments)
本文档纳入了大量互联网协议专家（包括大学与研究实验室、供应商和政府机构的代表）的贡献与评论。它主要由互联网工程任务组 (IETF) 的主机要求工作组 (Host Requirements Working Group) 汇编而成。
编辑特别希望感谢以下人员的不懈奉献，他们在过去 18 个月中参加了许多漫长的会议，并产生了 300 万字节的电子邮件以促成此文档：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) 和 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) 和 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) 和 Rayan Zachariassen (Toronto)。
我们向所有人致以谢意，包括任何可能不慎被遗漏在名单之外的贡献者。