反向地址转换协议

剑心通明

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.,"An
Ethernet
AddressResolutionProtocol",
RFC
826,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()，
从队列中取出第一项返回给用户进程，因为内核不能在中断级等待直到用户进程回
应，它或者放弃（假设请求主机一定时间后会重传请求包），或者如果第二个输入输
出控制把请求拷贝到内核，在那个时候应答。


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/4206/showart_506547.html