rfc1287.txt

很多RFC的中文文档

不久以前，I n t e r n e t 被定义为I P 网络连通性( I P 和I C M P 过去是、现在仍然是
唯一“需要”的I n t e r n e t 协议)。如果我能p i n g 你，你能p i n g 我，那么我们都在I n 
t e r n e t 上，同时，I n t e r n e t 令人满意的工作定义可构想为I P 对话系统的接近可过渡
的最后结果。这样的I n t e r n e t 模型是简单的、统一标准的，或许最重要的是可测试的。
I P 网络连通性模型可清楚地判别系统是否“在I n t e r n e t 上”。
随着I n t e r n e t 的增长及其使用的技术已广泛的被商界接受，对一个系统“在I n t e 
r n e t 上”的含义已经有所改变，应当包括：
· 具有部分I P 网络连通性，受限于策略过滤器的任何系统。
· 运行T C P / I P 协议集，不管是否从Internet 的其他部分实际上可接入的任何系统。
· 能交换RFC 822 邮件，无需邮件网关的干预或邮件对象的转换的任何系统。
· 有e - m a i l 连通到I n t e r n e t ，不论是否需要邮件网关或邮件对象转换的任何
系统。
对I n t e r n e t 的这些定义仍是基于原始的网络连通性概念，只是“栈的向上移动”。
在此，基于有区别的统一概念，提出I n t e r n e t 的新定义：
· “老的”I n t e r n e t 概念：以I P 为基础,组织的原则是I P 地址，也就是一个公
共的网络地址空间。
· “新的”I n t e r n e t 概念：以应用为基础,组织的原则是域名系统和目录，也就是
一个公共的(虽然必定是多形式的)应用名字空间。
这就告诉我们，“连接的状况”概念传统上是与I P 地址( 通过网络号)紧密联系在一起
的，应该代之以与存放在分布式I n t e r n e t 目录中的名字和相关标识信息联系在一起的。
I n t e r n e t 基于名字的定义意味着一个大得多的I n t e r n e t 社区，以及一个更为动态( 和
不可预测的) 可运转的I n t e r n e t 。对I n t e r n e t 体系结构的争论，是基于在很宽的范围
内对未来可能发展的适应性，而不局限于原来的设想。
3．2 基于过程的多协议Internet 模型
与其制订一个特殊的“多协议I n t e r n e t ”，接受一个预先确定特定协议数量的体系
结构，倒不如建议采用一个面向过程的I n t e r n e t 模型，它可以适应不同的协议体系结构，
符合传统的“能工作”原则。
面向过程的I n t e r n e t 模型，作为一个基本前提，主张不包括稳定状态“多协议I n t e 
r n e t ”的体系结构。最基本的驱动I n t e r n e t 进化的力量不是推动它朝多协议多样化发
展(虽然事实上永远不可能达到)。要说明的是I n t e r n e t 发展的趋势是向同质性进化，作
为最“热动稳定”状态，
下面描述一个新的基于过程的Internet 体系结构的四个部分：
第1 部分：核心I n t e r n e t 体系结构。
这是传统的基于T C P / I P 的体系结构。是I n t e r n e t 进化的“磁铁中心”，公认( 1 )
同质性仍然是处理互连网多样化的最好方法；( 2 ) I P 网络连通性仍然是I n t e r n e t 的最
佳基本模型(在全球I n t e r n e t 中，不论I P 无处不在的实际状态是否是一个现实)。
一开始，I n t e r n e t 体系结构只包括第1 部分。然而I n t e r n e t 的成功在于它超出
了原来的设想。无处不在和高度统一，对极大地丰富Internet “基因库”作出了贡献。
新I n t e r n e t 体系结构增加的两个部分扩大了I n t e r n e t 的广度和深度。
第2 部分：链路共享。
传输媒体、网络接口及低层链路协议等物理资源是由多个非交互的协议集所共享的。这
部分体系结构被认为是必须且适合于共存的，但不涉及到互操作性；被称为ships in the night 
( S . I . N . )。
当然，共存的协议集实际上不是纯粹孤立的；在真正的I n t e r n e t 系统中，S . I . N .
会引发管理、无冲突、协调和公平性等议题。
第3 部分：应用互操作性。
虽然缺乏互连普遍性(即“基础栈”的互操作性)，但只要在I n t e r n e t 系统的不相邻
社区之间安排应用的基本语义能以传递信息，仍然可能获得普遍的应用功能。这可以通过应
用转发站，或者由用户代理，对不同的由共同语义表示的应用服务提供一致的虚访问方法来
完成。
体系结构的这一部分，强调了I n t e r n e t 的最终作用是作为应用间的通信基础，而不
是它本身的结局。在一定程度上，使一个应用群体和他们的用户能够从一个基础协议集过渡
到另外一个，而不会发生难以接受的功能丢失，这可被称为“过渡起动器”。
将第2 和第3 部分加入到原始的I n t e r n e t 体系结构中，充其量是一件好坏半掺的
事情。虽然大大增加了I n t e r n e t 的广度和I n t e r n e t 社区的规模，但也会引入复杂性、
价格和管理等重大问题，同时还会出现功能的丢失(特别对第3 部分而言)。第2 和第3 部
分不可避免地背离了第1 部分所表示的同质性，但这是我们所不希望的。为了扩展I n t e r n 
e t 广度，某些功能丢失了，还要承受附加的系统复杂性和成本。而在一个完美的世界中，
应该不需付出这些代价就可换得I n t e r n e t 的进化和扩展。
目前有一种趋势，I n t e r n e t 的进化倾向于第1 部分表示的同质性体系结构，而不是
第2 和第3部分表示的折衷的体系结构。第4 部分表达了这种趋势。
第4 部分：混合/集成。
第4 部分认识到可以从不同的I n t e r n e t 协议体系结构中集成类似的元素以形成混
合体，以便减少I n t e r n e t 系统的多样化和复杂性。同时也认识到可以影响已存在的I n t e 
r n e t 基础设施以便I n t e r n e t 吸收“新东西”，并把已建立的I n t e r n e t 的测试、评价
和应用实践融入到“新东西”中去。
本部分表达了I n t e r n e t 的发展趋势，作为一个系统，试图回到原来由第1 部分统一
的体系结构所表示的“美好的状态”。虽然I n t e r n e t 将永远不会在未来的任意时刻回到
统一的状态，但这是一个对I n t e r n e t 进化起作用的力量。
按照这个动态的进程模型，在T C P / I P 栈上通过RFC 1006 运行X . 4 0 0 邮件，集成
I S - I S 选路，传送网关以及对I P 和C L N P 协议的单个共同后继协议的开发，都是很好
的例子。在第1 部分主张的“磁场”影响下，参照第4 部分混合的动态，它们显示了背离
第2 和第3 部分的非统一性，而走向更好的同质性。
4．安全体系结构
4．1 哲学准则
I n t e r n e t 安全性体系结构开发的主题是简单、可测试性、可信度、采用的技术和安
全周界
标识。
· 安全性比协议和密码保密措施要求更多。
· 安全性体系结构和策略应该简单且容易理解。复杂性会引起错误理解和不良的实现。
· 实现应该是可测试的，以便确定是否满足了策略。
·我们认为使任何安全性体系结构运行的硬件、软件和人是可以信任的。假设安全性策
略实施的技术设备至少和个人计算机及工作站具有同样的能力。我们不需要能力差的部件受
到自保护(但可能会用诸如链路级密码编码设备进行外部补救)。
· 最后，认定安全性有效保护的周界是最根本的。
4．2 安全性周界
有4 种可能的安全性周界：链路级、网络/子网级、主机级和进程/应用级。每种施加不
同的需求，能够接纳不同的技术，并能对何种系统部件可以被认为是有效的做出不同的假设。
隐私强化邮件是一种进程级安全系统的例子，另一个例子是为S N M P 提供身份验证
和保密。主机级安全性一般是在主计算机的通信口上用一个外部安全机制。网络或子网安全
性则应用从子网到“外部”的网关/路由器上的外部安全性能力。链路级安全性采用传统的
点对点或媒体级(如以太网)密码编码机制。
关于网络/子网安全性保护存在许多开放的问题，不单是主机级(端/端)安全性方法与网
络/子网级安全性方法之间存在潜在的不匹配，而且网络级保护也不能处理安全性周界内出
现的威胁。
在进程级采用保护，假定基础的程序和操作系统机制是可以信任的，不会由于使用了相
应的安全机制而妨碍应用程序。当安全性周界在系统体系结构中向下移至链路级，就要做有
关安全威胁的许多假设，以便得出这样的论点，就是在一个特定周界的实施是有效的。例如，
如果只有链路级使用加密编码，我们可以假设来自外部的攻击，只通过通信线，那么主机、
交换机和网关实际上是被保护的，同时人和所有部件中的软件都是可以信任的。
4．3 期望的安全性服务
如果在系统的应用级和较低级实现选定和非选定的接入控制，则需要可验证的正规的名
字。除此之外，还需要实施完整性( 防修改、防欺骗、防重放)，保密性和防止否认服务。
在某些情况下，可能还需要防止报文传输的否认或防止秘密信道。
已经有一些标准部件用以建立I n t e r n e t 安全系统。可以采用密码算法(如D E S 、R 
S A 、E lG a m a 1 和其他可能的公共密钥和对称密钥算法)，也可以采用如M D 2 和M D 5 
的散列函数。
根据O S I 的意义需要可鉴别的名字，并且为了便于人们了解标识符和目录服务，非常
需要一个指派标识符以及广泛使用目录服务的基础设施。把公共密钥与可鉴别的名字捆绑在
一起，并把能力和许可与可鉴别的名字捆绑在一起的认证概念，具有很多优点。
在路由器/网关级，采用地址和协议过滤器及其他配置控制，能有助于形成一个安全性
系统。把建议的O S I 安全性协议3 ( S P 3 )和安全性协议4 ( S P 4 )作为I n t e r n e t 安全性
体系结构的可能要素, 要给予认真的考虑。
最后，必须看到，在未实施安全存储的P C 或笔记本电脑系统上，安全地存储秘密信
息(诸如一个公共密钥对的秘密部分)，还没有好的解决方案。
4．4 建议的行动
建议采取下列行动：
1：安全性参考模型。
需要建立一个I n t e r n e t 的安全性参考模型，并迅速地得到开发。该模型应该建
立目标周界，并用文件形式建立安全性体系结构目标。
2：隐私强化邮件( P E M )。
对于隐私强化邮件，最关键的步骤看来是建立：( 1 )认证生成和管理基础设施；( 2 ) 
X . 5 0 0目录服务以提供通过可鉴别的名字访问公共密钥。在推广使用本系统时，还需
要对专利方面的限制和出口限制给予认真关注。
3：分布式系统安全性。
对分布式系统的应用，不论是简单的客户机/服务器系统还是复杂的分布式计算环
境，都需要检查安全设施。例如，对授予与可鉴别的名字捆绑在一起的许可/能力的认
证的实用性应受到检查。
4：主机级安全性。
对面向主机的安全性，应当对S P 4 予以评估，S P 3 也在考虑之列。
5：应用级安全性。
不论是为了服务的直接实用性(如P E M . S N M P 身份验证)，还是为了获得能够形成I 
n t e r n e t安全性体系结构精华的有价值的实际经验，都应该实施应用级安全性服务。
5．业务流控制与状态
目前的I n t e r n e t 平等地处理所有的I P 数据报。每个数据报对同一连接、同一
应用、同一应用类别、同一用户类，不论它和其他包有任何关系，都是独立地转发的。
虽然在I P 头中定义了服务类型位和优先权位，但通常都没有实施，事实上还不清楚如
何去实施它们。
众所周知，未来的I n t e r n e t 需要支持尽力而为所不能满足的大量应用，如电视
会议的包图像和语音。为了处理实时业务流，要求在路由器中有以附加的状态来控制的
业务流控制机制。
5．1 假设和原则
· 假设：I n t e r n e t 需要为业务流的特定子集支持性能保证。
遗憾的是对术语“性能”、“保证”或“子集”，远不能给出精确的定义。研究仍需
要对这些问题做出回答。
· 默认的服务将继续是当前无服务保证的“尽力而为”数据报分发服务。
· 路由器机制可分割为两部分：( 1 )转发路径；( 2 )发生在后台的控制计算(如选路)。
转发路径必须高度优化，有时由硬件辅助完成，因此相对而言很昂贵，而且难于变
更。运行在转发路径上的业务流控制机制，是由发生在后台的选路和资源控制计算创建
的状态来控制的。在改变路由器的转发路径时，最多起动一次，所以最好一开始就使它
正确。
· 新的扩展必须运行在一个高度异质的环境中。在该环境中，某些部分将永远不支持
保证。对一个路径上的某些段(如高速局域网)，即使当显式资源预留不用时，“超配给”
(即超过容量)也会对实时业务给予满足要求的服务。
· 组播分发或许是最根本的。
5．2 技术议题
需要解决的技术议题，包括：
(1) 资源建立。
为了支持实时业务流，从源到目的地的路由上的路由器中需要预留资源。该新的路
由器状态应该是“硬”的(如建立连接)还是“软”的(即缓冲的状态)？
(2) 资源捆绑与路由捆绑。
选择从源到目的地的一条路由传统上是由一个动态选路协议来完成的。资源捆绑和
选路可以重叠在单个复合进程中，或者也可以基本上独立地完成。这就要求在复杂性和
效率之间折衷考虑。
(3) 另一组播模型。
I P 组播用一个逻辑寻址模型，在该模型中，目标地址本身与一个组联系。在S T- 2 
中，一个组播会话中的每个主机在它的建立包中包括一系列显式目标地址。每一种方法
都有优点和缺点。当前还不十分清楚对n 路电视会议而言，哪个会占优势。
(4) 资源建立与行政管理域间的选路。
不论倾向于哪种资源保证，必须保持穿越一条任意的端对端并包括多个A D 的路
由。因此，任何资源建立机制必须与包含在IDPR 中的路由建立机制平稳地配合。
(5) 计费。
资源保证子集(“类别”)可以是自然的计费单位。
5．3 建议的行动
此处所谓的行动是指对上面列出的技术议题的进一步研究，紧随其后的是相应协议
的开发和标准化。D A RT n e t ，D A R PA 研究测试床网络，在本研究中将起重要作用。
6．现代应用
人们不禁要问“我们想要何种基于网络的应用，为什么现在还没有？”很容易列出
一张潜在应用的大表，其中许多都将基于客户机/服务器模型。然而问题中更有意思的
是：“为什么还没有人来做呢？”回答是：方便应用程序编写的工具尚不存在。
首先，对于许多将用于穿越网络的数据术语，需要一套公共交换格式。定义了公共
交换格式后，还需便于开发应用程序移动数据的工具。
6．1 公共交换格式
为使信息有意义，应用程序必须知道它们要交换的信息的格式。考虑下面的格式类
型：
(1) 文本—文本是最标准的，但今天的国际性I n t e r n e t 还需要有除了USASCII 
以外的字符集。
(2) 图像—当进入“多媒体时代”，图像变得越来越重要，但需要对如何在信息包
中表示图像信息取得一致。
(3) 图形—和图像一样，矢量图形信息需要一个共同的定义。有了定义的格式才能
交换类似结构蓝图的细节。
(4) 视频—先要知道从网络上来的视频信息的格式，才能在工作站上运行视频窗
口。
(5) 模拟音频—当然，人们需要的是伴有声音的视频，但这样的格式应该可以表示
所有类型的模拟信号。
(6) 显示—我们打开工作站上的窗口，并打开另一个人的工作站上的窗口，给它显
示与研究项目有关的某些数据，所以需要一个通用的窗口显示格式。
(7) 数据对象—对进程间的通信，类似整数、实数、串等数据的格式需要一致。
这些格式的相当一部分正在由几个标准组定义。我们需要为Internet 的每一类取得
一种一致的格式。
6．2 数据交换方法
应用程序将需要下列的数据交换方法：
(1) 存储转发。
不是每个人所有时间都在网上。需要一个标准手段向有时连在网上的主机提供信息
流，也就是需要一个通用的存储转发服务。组播也应包括在这一服务中。
(2) 全球文件系统。
在网上，大部分数据访问可以被分解成单个文件访问。如果有一个真正的全球文件
系统，那就能访问I n t e r n e t 上的任何文件(假定被许可的话)。你曾经需要用F T P 
吗？
(3) 进程间通信。
对一个真正的分布式计算环境，需要通过一些手段使进程在网络上能通过一个标准
方法来交换数据。这样的需求包括R P C 、A P I 等。
(4) 数据广播。
许多应用程序要求发送同样的信息到其他许多主机，因此需要一个标准且高效的方
法来完成这功能。
(5) 数据库访问。
对于好的信息交换，需要为访问数据库指定一个标准方法。全球文件系统能使你获
得数据，但数据库访问方法将告诉你有关它的结构和内容。
上述许多项正在由其他组织着手拟订，但对Internet 的互操作性，还需要在方法上
取得一致。
最后，现代应用需对本文中两个较早领域的问题寻找解决方案。从业务流控制与状
态领域而言，应用需要发送实时数据的能力。这意味着数据能在一个确定的时间范围内
分发。从安全性领域而言，应用也需要全球身份验证和访问控制系统。今天的Internet
由于缺乏可信度和安全，失去了许多有用的应用。这要求在明天的应用中得到解决。
7．参考资料
[1]  Cerf, V. and R. Kahn, "A Protocol for Packet Network
        Intercommunication," IEEE Transactions on Communication, May
        1974.

   [2]  Postel, J., Sunshine, C., and D. Cohen, "The ARPA Internet
        Protocol," Computer Networks, Vol. 5, No. 4, July 1981.

   [3]  Leiner, B., Postel, J., Cole, R., and D. Mills, "The DARPA
        Internet Protocol Suite," Proceedings INFOCOM 85, IEEE,
        Washington DC, March 1985.  Also in: IEEE Communications
        Magazine, March 1985.

   [4]  Clark, D., "The Design Philosophy of the DARPA Internet
        Protocols", Proceedings ACM SIGCOMM '88, Stanford, California,
        August 1988.

   [5]  Mogul, J., and J. Postel, "Internet Standard Subnetting
        Procedure", RFC 950, USC/Information Sciences Institute, August
        1985.

   [6]  Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
        1034, USC/Information Sciences Institute, November 1987.