mogul@SU-NAVAJO.ARPA (Jeff Mogul) (07/08/86)
From: mills@dcn6.arpa
No gateway implementation known to me (except the fuzzball as of
today) supports the ICMP Address Mask messages described in
RFC-950.
I looked at the 4.3BSD source code; it appears to support the Request
message, although I haven't tested an actual running system.
I would expect that the Proteon gateway supports this as well, since
Noel Chiappa is a partisan.
This is the only known case that requires broadcast of an ICMP
message, which not only complicates the implementations, but
suggests that maybe something is broken in the model.
I think what it really means is that it is the first ICMP-level
function designed with the knowledge that broadcast is possible.
I see nothing wrong with the current model; the original model
(that broadcast is not available) was what was broken. Having
said that, I must hasten to add that broadcasting should be done
only when necessary: when you don't know who to talk to or when
(nearly) every host is interested in what you have to say. ARP
is a good example; rwho is a rotten example.
The real
problem is that the ARP/RARP semantics are simply not rich enough
and should be expanded to include the mask in the first place. For
instance, a RARP reply should include not only the specific host
address, but also the address mask associated with its subnet.
Also, if promiscuous ARP is used to bypass a specific gateway
address, an ARP reply should include the address mask associated
with the subnet the address belongs to (if known).
The requisite semantics and packet formats might not be hard to
provide, since ARP and RARP are quite generic. While adding the
subnet mask, the type-of-service mask should also be added. The
ICMP Address Mask messages should be junked.
This would be a nice optimization of RARP+Address Mask, but it's not
a replacement. RARP is part of the ethernet layer (well, the data
link layer, but it's only available on ethernets now) but the Address
Mask request is important to the IP layer itself. I don't think
that, as a general policy, the ICMP Address Mask function should be
removed and pushed into RARP.
In your environment [which I would attack on aesthetic grounds
as a perversion of what is meant by a "local area network", but
I'll grant that while it is ugly it is not likely to go away],
"piggybacking" extra info on the RARP reply might be a good idea,
avoiding the ICMP broadcast unless something goes wrong. However,
this would require modifying RARP.
Anyway, you don't have to modify the RARP protocol to avoid doing
the second broadcast. If we assume that a host which responds to
an RARP can be trusted to know the correct mask (an assumption you
already have made) then once you get an RARP response, you know
the address of a host to which you can send a unicast ICMP Address
Mask message.
By the way, I don't understand this sentence:
Also, if promiscuous ARP is used to bypass a specific gateway
address, an ARP reply should include the address mask associated
with the subnet the address belongs to (if known).
If "promiscuous ARP" means "gateway responds to ARP on behalf of
a foreign host" [commonly known as "the ARP kludge"] and "the address"
is the target IP address, then I fail to see what is the use to the
requesting host of the subnet mask for a non-local wire.
-Jeff