Created an attachment (id=136) [details]
implement a God ARP 

I'm curious about the use cases for this.

Also, when it comes to naming, I prefer to stay away from the heavily
overloaded term "God"; can I suggest Oracle ARP, or maybe drop the "protocol"
altogether and call it OAR (Oracle Address Resolution) or PAR
(Perfect/Precomputed/... Address Resolution)?  

(In reply to comment #2)
> I'm curious about the use cases for this.

I think that the main use-case is modelizing a "stable" state where your
devices in the network have filled their resolution tables with valid entries.
I personally think that a better way to modelize this would be to ask users to
force these entries to contain valid entries by sending a bulk of initial ip
packets just for that but it seems that this opinion is not widely shared and I
can see how convenient the "dirty" oracle-like behavior could be.

> Also, when it comes to naming, I prefer to stay away from the heavily
> overloaded term "God"; can I suggest Oracle ARP, or maybe drop the "protocol"
> altogether and call it OAR (Oracle Address Resolution) or PAR
> (Perfect/Precomputed/... Address Resolution)?  

OAR or PAR sounds great to me.

Answering the "use case" question:

ARP is often an annoyance when doing testing at a higher level. It means the
first packet gets a longer RTT due to the ARP lookup. Often, when doing real
world testing, you just "prime" the ARP cache before doing your testing, to
remove this variability.

Example 1: I just want a "ping" application to measure network RTT. I'm not
interested in another layer having to do ARP here, I just want to know how long
my ping packets take to get through the network. By disabling ARP, we can be
sure that there is no variability introduced by the ARP mechanism.

I don't think ARP interactions are always of interest to a researcher. ns-2
didn't even have such interactions and for many studies, this was fine. It is
often reasonable to study a "steady state" system.

So, is adding/aggregating a new ARP implementation the right approach?  Should
the existing ARP just have a "disable/enable" attribute flag with
default=enable?  (where the "disabled" flag does an on-demand "cheating" by
seeding the arp table before it is queried). 

this perfect ARP will also need to be documented that it fails in proxy-arp
configurations.

(In reply to comment #5)
> So, is adding/aggregating a new ARP implementation the right approach?  Should
> the existing ARP just have a "disable/enable" attribute flag with
> default=enable?  (where the "disabled" flag does an on-demand "cheating" by
> seeding the arp table before it is queried). 

The above is just an implementation detail. The new ARP implementation is at
least nicer than adding another flag.

> this perfect ARP will also need to be documented that it fails in proxy-arp
> configurations.

What are these ?

(In reply to comment #6)
> (In reply to comment #5)
> > So, is adding/aggregating a new ARP implementation the right approach?  Should
> > the existing ARP just have a "disable/enable" attribute flag with
> > default=enable?  (where the "disabled" flag does an on-demand "cheating" by
> > seeding the arp table before it is queried). 
> 
> The above is just an implementation detail. The new ARP implementation is at
> least nicer than adding another flag.

I do not care strongly either way; was just a suggestion.

> 
> > this perfect ARP will also need to be documented that it fails in proxy-arp
> > configurations.
> 
> What are these ?

when one box is configured to reply for another address, for some reason. 
Coincidentally, one use case is when loopback interface is aliased (lo:0, lo:1)
so that a server can have multiple IP addresses on the same subnet.  Another
one is mobile IP home agent will reply for a roaming node.

It is not a big deal right now but when someone tries to support a proxy arp
case such as mobile IP, the perfect ARP would need to be modified to handle
that.
>