反向地址转换协议

【反向地址转换协议】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一样将是发送者

推荐阅读