反向地址转换协议

【反向地址转换协议】1.介绍
有些网络主机，例如无盘工作站，在启动的时候通常不知道协议地址，它们只知道
硬件接口地址。为了使用象IP这样的高层协议进行通讯，它们必须从外部来发现它们的
协议地址。我们的问题是没有标准机制来做这些。
Plummer的“地址转换协议”（ARP）[1]被设计用来解决一个相关的问题：给定主机
的协议地址得到它的硬件地址。这篇RFC提出了“反向地址转换协议” 。和ARP一样，
我们假设一种广播介质，例如以太网。
2.设计考虑
以下的考虑指导我们对RARP协议的设计。
A. ARP和RARP是不同的操作。ARP假设每一个主机都知道它的硬件地址和协
议地址间的映射。一个小缓存存放了收集到的关于其他主机的信息。所有的主机在
状态上是平等的，没有客户机和服务器的区别。
另一方面，RARP需要一个或者更多的服务器主机来维护一个存有从硬件地址
到协议地址的映射的数据库，并对客户机的请求作出应答。
B. 前面提到RARP需要维护大数据库的服务器主机，这并不是所希望的，在某
些情况下不可能在操作系统的内核中维护这样一个数据库。因此，大多数实现需要
和内核外的程序做某种形式的互操作。
C. 实现的简单和对已存在主机软件影响最小是重要的，设计一个需要改变每一个
主机的软件（而不管其是否参与）的协议是错误的。
D. 为了最小化开发成本和费用，希望考虑和已有软件共享代码的可能性。
3.推荐协议
我们建议RARP作为数据链路层单独的协议。例如，假如介质使用以太网，RARP
包和ARP包将有不同的以太网类型。这意味着ARP和RARP是两种不同的操作，所有
的主机并不平等地支持它们。对已存在系统的影响也最小，已有的ARP服务器不会被
ARP包弄糊涂。它把RARP看作一个能把硬件地址映射到任何高层协议地址的常用工
具。
这个方法使RARP客户端主机的实现最简单，但同时也使得RARP服务器端主机的
实现很困难。然而这种困难是没办法的，从附录A中描述的4.2BSDUnix下两种可能的
实现就可以看出。
RARP使用和ARP相同的包格式。
ar$hrd（硬件地址空间）16比特
ar$pro（协议地址空间）16比特
ar$hln（硬件地址长度）8比特
ar$pln（协议地址长度）8比特
ar$op（操作码）16比特
ar$sha（源硬件地址）n比特，n来自ar$hln字段
ar$spa（源协议地址）m比特，m来自ar$pln字段
ar$tha（目的硬件地址）n比特
ar$tpa（目的协议地址）m比特
ar$hrd、ar$pro、ar$hln和ar$pln与ARP相同（见[1]）。
例如，假设硬件地址是48比特以太网地址，协议地址是32比特Internet地址，我
们希望决定对应已知的以太网地址的Internet地址，那么在每个RARP包中，ar$hrd=1
（以太网），ar$pro=2048（IP包的以太网类型），ar$hln=6，ar$pln=4 。
有两个操作码：3（请求）和4（应答）。1或2在[1]中有相同的意义，带有这样操
作码的包被当作ARP包通过。带有其它操作码的包并没有定义。和ARP一样，RARP
没有“找不到”和“错误”的包，因为许多RARP服务器可自由地应答请求。假如经过
一段时间后，没有收到应答，RARP请求的发送者将超时。
RARP包中ar$sha、ar$spa、ar$tha和ar$tpa字段的解释如下：
当操作码是3（请求）：
ar$sha是发送者的硬件地址
ar$spa未定义
ar$tha是目的硬件地址
当发送者希望知道自己的协议地址的情况下，和ar$sha一样将是发送者
的硬件地址。
ar$tpa未定义
当操作码是4（应答）：
ar$sha是响应者的硬件地址（应答包的发送者）
ar$spa是响应者的协议地址（见下面的注重）
ar$tha是目的硬件地址，必须和请求包中得到的相同
ar$tpa是目的协议地址，即需要得到的地址。
注重：在操作码为4的包中ar$spa字段填响应者的协议地址，只是为了方便。例如，
系统同时使用ARP和RARP，有效的协议-硬件对（ar$spa，ar$sha）会减少以后发ARP
请求的需要。
4.参考
[1] Plummer,D.,"AnEthernetAddressResolutionProtocol",RFC826,MIT-LCS,
November1982.
附录A.4.2BSDUnix下的两个实现例子
下面的实现描述概括了4.2BSDUnix下实现RARP服务器的两种不同方法。
A. 提供在内核外访问数据链路层包。RARP服务器完全在内核外实现，只在收发RARP
包时和内核进行互操作。内核被修改成能提供接口来访问这些包，目前4.2内核只
答应访问IP包。CMU的“包过滤”伪驱动是提供这种功能的现有机制。它在CMU
和斯坦福实现“用户级”网络服务器排序上，使用的很成功。
B. 在内核里维护一个数据库表项的缓存。整个RARP服务器数据库通过一个用户进程
在内核外维护。RARP服务器本身直接在内核中实现，并为应答维护一个小的数据
表项缓存。这个缓存和传输ARP的相同。这个缓存通过两个新的输入输出控制从实
际的RARP数据库得到（这像SIOCIFADDR，因为他们不直接和具体的套接字相关）。
一种是：“睡眠直到需要进行地址转换，然后把请求直接输出到用户进程”；另一种
是：“把地址转换输入内核表” 。因此，当内核不能在缓存中发现一个表项的时候，
把这个请求放到队列中，然后调用wakeup() 。第一个输入输出控制的实现是sleep()，
从队列中取出第一项返回给用户进程，因为内核不能在中断级等待直到用户进程回
应，它或者放弃（假设请求主机一定时间后会重传请求包），或者假如第二个输入输
出控制把请求拷贝到内核，在那个时候应答。