Can ARP packet have zero or Broadcast address as Soure IP address??
Anand
When I send an ARP request with Source IP address as zero or Broadcast,
I am getting reply from windows/Linux PC.
But a zero or broadcast ipaddress is invalid and no host will have
these values, then Why should windows/linux respond for such a packet
with invalid ipaddress?
Is there any standard supporting these values?
Regards,
Anand.
Walter Roberson
Anand <an...@iwavesystems.com> wrote:
:When I send an ARP request with Source IP address as zero or Broadcast,
:I am getting reply from windows/Linux PC.
:But a zero or broadcast ipaddress is invalid and no host will have
:these values,
Someone pointed out to me the other day that a DHCP request must
be sent out with an IP address of 0.0.0.0 (since it doesn't have
a real IP yet to use...)
--
Entropy is the logarithm of probability -- Boltzmann
James Carlson
> When I send an ARP request with Source IP address as zero or Broadcast,
> I am getting reply from windows/Linux PC.
Such packets are called "probes." They're commonly used to test
whether anyone on the network currently holds that address without
updating (and possibly corrupting) anyone's ARP cache.
They're typically used for duplicate address detection. When you
first configure an interface, you send out a probe to see if anyone
holds the address already. If so, then back off and either notify an
administrator or send a DHCP DECLINE and try to get a new address.
> But a zero or broadcast ipaddress is invalid and no host will have
> these values, then Why should windows/linux respond for such a packet
> with invalid ipaddress?
It isn't IP. It's ARP.
> Is there any standard supporting these values?
RFC 826.
--
James Carlson, KISS Network <james.d...@sun.com>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Anand
> :But a zero or broadcast ipaddress is invalid and no host will have
> :these values,
>
> Someone pointed out to me the other day that a DHCP request must
> be sent out with an IP address of 0.0.0.0 (since it doesn't have
> a real IP yet to use...)
Yes, it is possible. A host may send ARP initial broadcast packet with
0.0.0.0 IP address. And everyother host in the network will receive
this packet. Upon receiving such a packet the other hosts should not
create any entry for this IPaddress and mac value in its ARP cache.
Because 0.0.0.0 is an invalid ipaddress. So the receiving hosts should
simply ignore this packet.
Is it right?
Then why a host replying for an ARP request with source IP address
0.0.0.0?
Anand
>whether anyone on the network currently holds that address without
>updating (and possibly corrupting) anyone's ARP cache.
An ARP probe will always have some valid IP address in its Source IP
address field. It is same as the Gratitious ARP used for duplicate IP
address detection.
>> But a zero or broadcast ipaddress is invalid and no host will have
>> these values, then Why should windows/linux respond for such a packet
>> with invalid ipaddress?
> It isn't IP. It's ARP.
Yes. I am talking about the Source IP address of an ARP request packet.
>> Is there any standard supporting these values?
> RFC 826.
This RFC does not say anything about IP address or MAC address
validations!!. :-(
i.e it simply accepts whatever value in the IP address or MAC address
field.
James Carlson
> >Such packets are called "probes." They're commonly used to test
> >whether anyone on the network currently holds that address without
> >updating (and possibly corrupting) anyone's ARP cache.
>
> An ARP probe will always have some valid IP address in its Source IP
> address field. It is same as the Gratitious ARP used for duplicate IP
> address detection.
Not true; probing and gratuitous ARP are very different things. See,
among other sources:
Cheshire, Stuart, et al., "Dynamic Configuration of IPv4 Link-
Local Addresses," July 2004 (work-in-progress).
... available in your local Internet Draft archives. The important
part is that if you're not sure whether your address is a duplicate,
you should be using 0.0.0.0, so that you don't corrupt everyone else's
ARP caches with your broadcasted requests.
A gratuitous ARP *forces* everyone else to update their caches. If
you're defending an address that you legitimately have, that makes
sense. But if you're probing, it does not.
> > It isn't IP. It's ARP.
>
> Yes. I am talking about the Source IP address of an ARP request packet.
Still, it's ARP. As far as ARP is concerned, this is part of the data
that the message carries. The only node addressing that's going on
here is the L2 addressing.
> >> Is there any standard supporting these values?
>
> > RFC 826.
>
> This RFC does not say anything about IP address or MAC address
> validations!!. :-(
Exactly.
> i.e it simply accepts whatever value in the IP address or MAC address
> field.
Right.
Anand
> Cheshire, Stuart, et al., "Dynamic Configuration of IPv4 Link-
> Local Addresses," July 2004 (work-in-progress).
Thank you very much for notifying this document.
My conclusion is, Reception of ARP Request packet with Source IP
address 0.0.0.0 (or 255.255.255.255) is not *invalid*. However the
receiving host should not create an entry for this IP address in ARP
cache eventhough the Target IP address is
host's local address.
So, simply implementing as per RFC 826 is not enough for ARP
processing.
>> RFC 826:
> ?Am I the target protocol address?
> Yes:
> If Merge_flag is false, add the triplet <protocol type,
> sender protocol address, sender hardware address> to
> the translation table.
It will be better if there is a validation check for 0 or broadcast IP
address before creating entry in ARP table.
Anand
This link also talking about the same topic. "0.0.0.0 Entry in Arp
Table"
Regards,
Anand.
James Carlson
> > Cheshire, Stuart, et al., "Dynamic Configuration of IPv4 Link-
> > Local Addresses," July 2004 (work-in-progress).
>
> Thank you very much for notifying this document.
>
> My conclusion is, Reception of ARP Request packet with Source IP
> address 0.0.0.0 (or 255.255.255.255) is not *invalid*. However the
> receiving host should not create an entry for this IP address in ARP
> cache eventhough the Target IP address is
> host's local address.
If it creates such an entry, that's fine. The entry will never be
consulted for anything because it's not a possible destination
address. It won't matter.
> So, simply implementing as per RFC 826 is not enough for ARP
> processing.
Huh?
> >> RFC 826:
> > ?Am I the target protocol address?
> > Yes:
> > If Merge_flag is false, add the triplet <protocol type,
> > sender protocol address, sender hardware address> to
> > the translation table.
>
> It will be better if there is a validation check for 0 or broadcast IP
> address before creating entry in ARP table.
No. It's not needed.
James Carlson
I've seen the same equipment mentioned in that thread do all sorts of
strange things with ARP.
I don't think that argues one way or the other about ARP itself.
(And to answer the question there: no, that's not UnARP. UnARP has no
hardware address. Which also happens to confuse that particular
device ...)