组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：沈进（simon_shen&nbsp;&nbsp;&nbsp;shen_jin@263.net）<br />
译文发布时间：2001-8-14<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group								Finlayson,&nbsp;Mann,&nbsp;Mogul,&nbsp;Theimer<br />
Request&nbsp;for&nbsp;Comments:&nbsp;903							Stanford&nbsp;University&nbsp;<br />
												June&nbsp;1984<br />
<br />
<br />
反向地址转换协议<br />
（RFC903——A&nbsp;Reverse&nbsp;Address&nbsp;Resolution&nbsp;Protocol）<br />
<br />
Ross&nbsp;Finlayson,&nbsp;Timothy&nbsp;Mann,&nbsp;Jeffrey&nbsp;Mogul,&nbsp;Marvin&nbsp;Theimer&nbsp;<br />
Computer&nbsp;Science&nbsp;Department<br />
Stanford&nbsp;University<br />
June&nbsp;1984<br />
本备忘录状态：<br />
	本RFC文档讲述了当工作站只知道硬件地址（例如：它们的物理网络地址）时，动态<br />
发现协议地址（例如：Internet地址）的一种方法。<br />
	本RFC文档讲述了ARPA网络社区的一种建议协议，需要讨论和建议去加强。<br />
目录<br />
1.介绍	1<br />
2.设计考虑	2<br />
3.推荐协议	2<br />
4.参考	3<br />
附录A.&nbsp;4.2BSD&nbsp;Unix下的两个实现例子	3<br />
<br />
1.介绍<br />
有些网络主机，例如无盘工作站，在启动的时候通常不知道协议地址，它们只知道<br />
硬件接口地址。为了使用象IP这样的高层协议进行通讯，它们必须从外部来发现它们的<br />
协议地址。我们的问题是没有标准机制来做这些。<br />
Plummer的“地址转换协议”（ARP）[1]被设计用来解决一个相关的问题：给定主机<br />
的协议地址得到它的硬件地址。这篇RFC提出了“反向地址转换协议”。和ARP一样，<br />
我们假设一种广播介质，例如以太网。<br />
2.设计考虑<br />
&nbsp;&nbsp;&nbsp;以下的考虑指导我们对RARP协议的设计。<br />
A.	ARP和RARP是不同的操作。ARP假设每一个主机都知道它的硬件地址和协<br />
议地址间的映射。一个小缓存存放了收集到的关于其他主机的信息。所有的主机在<br />
状态上是平等的，没有客户机和服务器的区别。<br />
另一方面，RARP需要一个或者更多的服务器主机来维护一个存有从硬件地址<br />
到协议地址的映射的数据库，并对客户机的请求作出应答。<br />
B.	前面提到RARP需要维护大数据库的服务器主机，这并不是所希望的，在某<br />
些情况下不可能在操作系统的内核中维护这样一个数据库。因此，大多数实现需要<br />
和内核外的程序做某种形式的互操作。<br />
C.	实现的简单和对已存在主机软件影响最小是重要的，设计一个需要改变每一个<br />
主机的软件（而不管其是否参与）的协议是错误的。<br />
D.	为了最小化开发成本和费用，希望考虑和已有软件共享代码的可能性。<br />
3.推荐协议<br />
我们建议RARP作为数据链路层单独的协议。例如，如果介质使用以太网，RARP<br />
包和ARP包将有不同的以太网类型。这意味着ARP和RARP是两种不同的操作，所有<br />
的主机并不平等地支持它们。对已存在系统的影响也最小，已有的ARP服务器不会被<br />
ARP包弄糊涂。它把RARP看作一个能把硬件地址映射到任何高层协议地址的常用工<br />
具。<br />
这个方法使RARP客户端主机的实现最简单，但同时也使得RARP服务器端主机的<br />
实现很困难。然而这种困难是没办法的，从附录A中描述的4.2BSD&nbsp;Unix下两种可能的<br />
实现就可以看出。<br />
RARP使用和ARP相同的包格式。<br />
ar$hrd&nbsp;（硬件地址空间）&nbsp;16比特<br />
ar$pro&nbsp;（协议地址空间）&nbsp;16比特<br />
ar$hln&nbsp;（硬件地址长度）&nbsp;8比特<br />
ar$pln&nbsp;（协议地址长度）&nbsp;8比特<br />
ar$op&nbsp;（操作码）&nbsp;16比特<br />
ar$sha&nbsp;（源硬件地址）&nbsp;n比特，n来自ar$hln字段<br />
ar$spa&nbsp;（源协议地址）&nbsp;m比特，m来自ar$pln字段<br />
ar$tha&nbsp;（目的硬件地址）&nbsp;n比特<br />
ar$tpa&nbsp;（目的协议地址）&nbsp;m比特<br />
ar$hrd、ar$pro、ar$hln和ar$pln与ARP相同（见[1]）。<br />
例如，假设硬件地址是48比特以太网地址，协议地址是32比特Internet地址，我<br />
们希望决定对应已知的以太网地址的Internet地址，那么在每个RARP包中，ar$hrd&nbsp;=&nbsp;1<br />
（以太网），ar$pro&nbsp;=&nbsp;2048（IP包的以太网类型），ar$hln&nbsp;=&nbsp;6，ar$pln&nbsp;=&nbsp;4。<br />
有两个操作码：3（请求）和4（应答）。1或2在[1]中有相同的意义，带有这样操<br />
作码的包被当作ARP包通过。带有其它操作码的包并没有定义。和ARP一样，RARP<br />
没有“找不到”和“错误”的包，因为许多RARP服务器可自由地应答请求。如果经过<br />
一段时间后，没有收到应答，RARP请求的发送者将超时。<br />
RARP包中ar$sha、ar$spa、ar$tha和ar$tpa字段的解释如下：<br />
当操作码是3（请求）：<br />
&nbsp;&nbsp;&nbsp;&nbsp;ar$sha是发送者的硬件地址<br />
&nbsp;&nbsp;&nbsp;&nbsp;ar$spa未定义<br />
&nbsp;&nbsp;&nbsp;&nbsp;ar$tha是目的硬件地址<br />
&nbsp;&nbsp;&nbsp;&nbsp;当发送者希望知道自己的协议地址的情况下，和ar$sha一样将是发送者<br />
的硬件地址。<br />
&nbsp;&nbsp;&nbsp;&nbsp;ar$tpa未定义<br />
当操作码是4（应答）：<br />
&nbsp;&nbsp;&nbsp;&nbsp;ar$sha是响应者的硬件地址（应答包的发送者）<br />
&nbsp;&nbsp;&nbsp;&nbsp;ar$spa是响应者的协议地址（见下面的注意）<br />
&nbsp;&nbsp;&nbsp;&nbsp;ar$tha是目的硬件地址，必须和请求包中得到的相同<br />
&nbsp;&nbsp;&nbsp;&nbsp;ar$tpa是目的协议地址，即需要得到的地址。<br />
&nbsp;&nbsp;&nbsp;&nbsp;注意：在操作码为4的包中ar$spa字段填响应者的协议地址，只是为了方便。例如，<br />
系统同时使用ARP和RARP，有效的协议-硬件对（ar$spa，ar$sha）会减少以后发ARP<br />
请求的需要。<br />
4.参考<br />
[1]	Plummer,&nbsp;D.,&nbsp;"An&nbsp;Ethernet&nbsp;Address&nbsp;Resolution&nbsp;Protocol",&nbsp;RFC&nbsp;826,&nbsp;MIT-LCS,&nbsp;<br />
November&nbsp;1982.<br />
附录A.&nbsp;4.2BSD&nbsp;Unix下的两个实现例子<br />
	下面的实现描述概括了4.2BSD&nbsp;Unix下实现RARP服务器的两种不同方法。<br />
A.	提供在内核外访问数据链路层包。RARP服务器完全在内核外实现，只在收发RARP<br />
包时和内核进行互操作。内核被修改成能提供接口来访问这些包，目前4.2内核只<br />
允许访问IP包。CMU的“包过滤”伪驱动是提供这种功能的现有机制。它在CMU<br />
和斯坦福实现“用户级”网络服务器排序上，使用的很成功。<br />
B.	在内核里维护一个数据库表项的缓存。整个RARP服务器数据库通过一个用户进程<br />
在内核外维护。RARP服务器本身直接在内核中实现，并为应答维护一个小的数据<br />
表项缓存。这个缓存和传输ARP的相同。这个缓存通过两个新的输入输出控制从实<br />
际的RARP数据库得到（这像SIOCIFADDR，因为他们不直接和具体的套接字相关）。<br />
一种是：“睡眠直到需要进行地址转换，然后把请求直接输出到用户进程”；另一种<br />
是：“把地址转换输入内核表”。因此，当内核不能在缓存中发现一个表项的时候，<br />
把这个请求放到队列中，然后调用wakeup()。第一个输入输出控制的实现是sleep()，<br />
从队列中取出第一项返回给用户进程，因为内核不能在中断级等待直到用户进程回<br />
应，它或者放弃（假设请求主机一定时间后会重传请求包），或者如果第二个输入输<br />
出控制把请求拷贝到内核，在那个时候应答。<br />
RFC903——A&nbsp;Reverse&nbsp;Address&nbsp;Resolution&nbsp;Protocol&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;反向地址转换协议<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />