In message <20000711234748.P7436@acheron.in.hades>, Mason Loring Bliss writes:
>That would be "e.g.", but, in any event, why maintain two configuration
>files and force the admin in question to remember to use a tool to
>keep them synchronized?

Because the two files represent different things.  See below.

>> Personally, I'd sao "No, it doesn't seem reasonable". But perhaps
>> others feel differently -- did you get an upswell of unicast emails
>> supporting the idea?
>
>There was one post on tech-userlevel suggesting this as a possible
>solution.

I saw no such post, could you please provide an explicit
citation? The closest I saw was greywolf's
<Pine.NEB.4.21.0007092024550.4248-100000@mage.starwolf.com>
suggesting such an option, but I saw no justification
for _why_ this is a good idea.

>This could be the right thing to do in the case of a gateway-type
>machine with one interface sitting on a potentially hostile network,
>where you do not want your arp tables maliciously stuffed with
>incorrect entries.

I suppose this may be the case. In the absence of a mechanism for
populating /etc/ethers with reliable information, I would not think
adding this option would be a good plan. Additionally, it does nothing
to address hosts not listed in the input file, which may imply a false
sense of security.

I don't think that we really support the idea of running 802.11-style
networks without running the ARP protocol. If we wanted to support
that (and I don't really think we should), a variety of other work
would need to be done to bulletproof things.


At the moment, the normal use of /etc/ethers is to provide reverse
translation of MAC addresses to names, for tools like tcpdump. In such
cases, /etc/ethers is usually not a reliable list of all MAC addresses
on a network. In many cases, /etc/ethers information is wrong due to
changes since the last time it was updated. Perhaps if folks are
rigorously using arpwatch or somesuch tool it might be up-to-date, but
then you are depending on ARP anyhow.


>Arp(8) already provides the -f flag, which suggests that there might be
>a need for users to load arp entries from a file.

Yes. Notice that that file contains additional data (flags: temp, pub)
as well as the info in /etc/ethers. I think it would be a mistake to
let /etc/ethers data be brought into the arp table without allowing those
specifiers, which the ethers(5) format does not allow.


>It would seem obvious that the data in /etc/ethers would be exactly
>what should be loaded in some cases.

Please don't use the word "obvious" to avoid providing justification.

Certainly you could put the data you want in /etc/ethers, and you
could put it in the input file for arp(8).  I think there are very few
people who would want to load the entire contents of /etc/ethers into
their ARP table.

Another observation is that /etc/ethers is used to translate MAC addreses
into names. Those names do not necessarily have to match up with DNS
names, nor with IP addresses, and frequently are concocted so they
are visibly convenient for tcpdump output.  They do not necessarily
map to IP addresses in /etc/hosts or the DNS. Obviously such a mapping
is necessary for arp(8).

My understanding is that the -f flag is intended for people who have
multiple static arp entries required in their environment (typically
published arp entries, but perhaps not always), and would like to
avoid having to run 'arp' multiple times. Typically, this would be a
much smaller set of entries then one might find in a typical populated
/etc/ethers file.

>In my specific case, it's exactly what I want.

Really? You have a non-hypothetical case where this is useful? Is it
the one you cited of a gateway machine that does not trust ARP (I find
this implausible)? Or do you have a different scenario?

>The /etc/ethers file is a general-purpose mapping of MAC addresses to
>host names.

I don't really think it is very general-purpose at all. 

> Not making use of it for arp(8) would seem a bit silly.

I don't think the use of arp(8) for entering static entries
is a very general-purpose task.


I'd be quite curious what practical, non-hypothetical uses might be.

--jhawk