rfc917.txt

中文RFC 384 篇

可以维护非局域网通讯的路由表，这就隐藏了大部分的子网结构。对子网和非子网都适
用的主机软件的‘最少调整模型’就是位掩码。
由于其自治性和已安装的软件的关系，以及没有一个优秀的工业标准的原因，麻省
理工学院不计划马上使用这个协议，而是使用一套单一的物理连接和包交换机制，和在
这套机制上的几个虚拟协议网络。麻省理工学院曾经试图在不同的协议间交换路由信
息，以及将一个协议包含在另一个协议中，从中得到一些教训。除了基本的硬件，协议
因该是严格独立的。使用ARP隐藏子网结构不是非常好，在一个复杂的系统（有环路
和不同的连接速率）中，ARP使地址操作过载。网关间需要一个更复杂的信息互换方
法。

   4．3 卡内基-梅隆大学（CMU）
卡内基-梅隆大学使用一个B类网络，网络被分为11个物理子网，2个3M的实验
以太网，7个10M以太网和2个ProNET环。虽然分配主机地址时，使第三个8位字
节相同的地址在同一个子网上，但这只是为了管理方便，而不是必须的。软件不知道这
个分配机制。
卡内基-梅隆大学使用一个基于ARP的网桥方案。当一台主机发出ARP请求，收
到的网桥将原来的地址映射放入缓存，并将请求传递给其它的电缆。当网桥收到一个有
目标地址的ARP回复时，从缓存中寻找将这个回复送到哪条电缆上。这样，网桥尝试
将ARP协议透明的扩展到不同类的多电缆环境中。这就要求网桥将一条电缆上的广播
变成所有连接着的电缆上的广播。所以这个算法只在没有连接环路的网络上可行。将这
个简单算法替换为支持冗余路径和减低广播负载的算法的工作正在进行中。
卡内基-梅隆大学使用支持3M以太网和10M proNET环的RFC-826 地址解析协
议。
因为卡内基-梅隆大学没有冗余的连接电缆，因此不用关心网桥的崩溃问题。网络
上150台主机也使网桥有足够的缓存，ARP广播使用的带宽也不大。
但卡内基-梅隆大学的网络会从单一连接的小网络发展成为有5000-10000台主机
的连接整个校园的大网络。基于ARP的网桥方案不再使用，需要一个有明确子网的系
统。中期的目标是建立一个可以引入没有修改的IP实现的环境。其目的是尽可能的的
保持对主机透明的路由机制。

5．地址格式因特网信报控制协议（ICMP）
5．1 描述
地址格式请求或地址格式回复
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     类型      |      代码     |          校验和               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           标识                |         序列号                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP字段：
地址
地址格式请求消息的源地址就是地址格式回复消息的目的地址。为了
构成回复消息，请求的源地址成为回复的目标地址，回复消息的源地
址就设成回复者的地址。“类型”设成“A2“，“编码”字段设为子
网字段的长度，然后计算校验和。如果请求的源地址是0，那么回复
的目标地址就设成广播地址。
因特网信报控制协议（ICMP）字段
类型
A1 表示地址格式请求消息
A2 表示地址格式回复消息
编码
0 代表地址格式请求消息
非0代表地址格式回复消息的子网字段长度
校验和
从因特网信报控制协议“类型”字段开始的16位的和的余数。计算
时，校验和应为0。其值以后可能被改变。
标识
匹配请求和回复的标识，可以是0。
序列号
匹配请求和回复的序列号，可以是0。

收到地址格式请求的网关要回复这个请求。它需要将“编码”字段置为请求的目表
地址网络的子网字段的长度。如果请求是广播的，其目标地址就是“这个网络”。
子网字段的长度可以是0-（31-N）， N是IP网络字段的长度（8，16或24）。
如果请求的主机不知道自己的地址，就可能把请求中的源地址置为0，回复则是广
播的。因为一个网络自由一种地址格式，所有就没有必要匹配请求和回复。这种方
式应尽量避免，因为它会增加不必要的网络流量。
类型A1可能从网关和主机收到
类型A2可能从网关和起网关作用的主机收到。


5．2 例子
下面例子中，我们假设请求主机的地址是36.40.0.123，网关是36.40.0.62，处于
网络36.0.0.0中，使用8位子网。
首先，假设广播是允许的，主机发送如下数据包：
源地址:          36.40.0.123
目标地址:        36.255.255.255
协议:            ICMP = 1
类型:            Address Format Request = A1
编码:            0
36.40.0.62将收到这个数据包，并回复如下：
源地址:          36.40.0.62
目标地址:        36.40.0.123
协议:            ICMP = 1
类型:            Address Format Reply = A2
编码:            8


下面的例子假设地址255.255.255.255 表示“广播到这个物理网络”。上面的例子
就无能为力了。因为这样的广播可能要广播到多个子网。我们建议的最有效的方法
是，主机首先找到自己的地址（可以使用在参考[4]中描述的“反向地址解析协议”），
然后将ICMP请求发送到255.255.255.255。
源地址:          36.40.0.123
目标地址:        255.255.255.255
协议:            ICMP = 1
类型:            Address Format Request = A1
编码:            0
网关就可以直接回复给请求主机。


假设36.40.0.123是无盘工作站，并不知道自己的主机号。它可以发送下面数据：
源地址:          0.0.0.0
目标地址:        255.255.255.255
协议:            ICMP = 1
类型:            Address Format Request = A1
编码:            0
36.40.0.62将收到这个数据包，并回复：
源地址:          36.40.0.62
目标地址:        36.40.255.255
协议:            ICMP = 1
类型:            Address Format Reply = A2
编码:            8


注意，网关使用最小的广播范围回复（发送到36.255.255.255将会在许多子网中
广播，而并不单单是需要的子网）。即使这样，这个广播也造成不必要的网络负载。
因此我们建议尽量少的使用“匿名（0.0.0.0）”源地址。
如果不允许广播，假设主机有邻接网关的硬编码信息，则36.40.0.123会发送：
源地址:          36.40.0.123
目标地址:        36.40.0.62
协议:            ICMP = 1
类型:            Address Format Request = A1
编码:            0
36.40.0.62 的回复和上例一样

注意
有些A类网络中的主机分配的主机号就是其以太网硬件地址的低24位。
我们讨论的因特网广播是基参考[6]的。
如果不支持广播，则假设有主机知道邻接网关地址，并发送ICMP到这个网关。
这就是前面提到的在同一个网络中，透明子网和显式子网的并存。

参考
D.R. Boggs, J.F. Shoch, E.A. Taft, 和 R.M. Metcalfe著，《Pup：一种因特网结构》， 
IEEE通讯学报， COM-28，4， 612-624页， 1980年4月
David D. Clark著《名字，地址，端口和路由》，RFC-814，MIT-LCS，1982年7月
Yogan K. Dalal 和 Robert M. Metcalfe著，《广播数据包的反向传递》，Comm. ACM 21, 
12,1040-1048页，1978年12月
Ross Finlayson, Timothy Mann, Jeffrey Mogul和 Marvin Theimer著，《逆向地址解析
协议》，RFC-903，斯坦福大学，1984年6月
R.M. Metcalfe 和 D.R. Boggs著，《以太网：分布式的局域网包交换》，Comm. ACM 
19,7, 395-404页， 1976年7月
Jeffrey Mogul著， 《广播数据包》， RFC-919，斯坦福大学， 1984年10月
Da Jeffrey Mogul 著，《一种以太网地址解析协议》，RFC-826，1982年9月
Jon Postel著，《因特网协议》，RFC-791， USC-ISI， 1982年9月。
Jon Postel著，《因特网信报控制协议》，RFC-792， USC-ISI，1981年9月


RFC917——INTERNET SUBNETS                                    因特网子网


1
RFC文档中文翻译计划