Subject: re: advice on reworking ARP to support IP->MAC addresses
To: None <email@example.com, tech-kern@NetBSD.ORG>
From: Keith Sklower <sklower@CS.Berkeley.EDU>
Date: 02/28/1996 10:59:51
Kirk McKusick forwarded Jonathan's mail, and since I'm working part
time for Randy Katz here (who is doing related research to what
Mary Baker is doing), it certainly would be appropriate for me
to collaborate specifically on the metricom driver.
In general, it was my intent that the routing table could be used for
IP->MAC addresses. The X.25 code does this, and I have some some
3/4's written code for IP/frame relay. You shouldn't expect to
user ether_output() as the if_output routine for the metricom
device, you should write a specific one for the metricom,
and it will probably be only on the order of 40 lines of code.
link layer routes can already be manually entered using the route command:
(e.g. route add -iface 184.108.40.206 -link me0:220.127.116.11.35.38.37)
(here me0 would be a hypothetical metricom interface. The phone number
is my phone number, but only seven digits worth).
You don't need a struct arpcom to do this at all; however, there
does need to be some means for a system to learn what telephone
number corresponds to IP address and neither Jonthan's message
nor the usenix paper (at least in my 3 minute scan of it using
ghostview) says how a system acquires this information.
If you squint your eyes hard enough, the metricom really isn't
that different from the ATM fabric or from X.25 or frame relay
in this respect; they are all non-broadcast shared media, and
there is an IETF working group proposing protocols for address
resolution and short-cut routing (rolc); one of the protocols
is called NARP (RFC1735), and it would be a service to the community if
we implemented it in a general way in the kernel as a cousin to ARP.