I have just started to learn about protocols. While studying the packets in wireshark, I came across a ARP request sent by my machine to my own IP. Here is the details of the packet :

  No.     Time        Source                Destination           Protocol Info
     15 1.463563    IntelCor_aa:aa:aa     Broadcast             ARP      Who has  Tell

Frame 15: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)
    Arrival Time: Jan  7, 2011 18:51:43.886089000 India Standard Time
    Epoch Time: 1294406503.886089000 seconds
    [Time delta from previous captured frame: 0.123389000 seconds]
    [Time delta from previous displayed frame: 0.123389000 seconds]
    [Time since reference or first frame: 1.463563000 seconds]
    Frame Number: 15
    Frame Length: 42 bytes (336 bits)
    Capture Length: 42 bytes (336 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:arp]
    [Coloring Rule Name: ARP]
    [Coloring Rule String: arp]
Ethernet II, Src: IntelCor_aa:aa:aa (aa:aa:aa:aa:aa:aa), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination: Broadcast (ff:ff:ff:ff:ff:ff)
        Address: Broadcast (ff:ff:ff:ff:ff:ff)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
    Source: IntelCor_aa:aa:aa (aa:aa:aa:aa:aa:aa)
        Address: IntelCor_aa:aa:aa (aa:aa:aa:aa:aa:aa)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: ARP (0x0806)
Address Resolution Protocol (request)
    Hardware type: Ethernet (0x0001)
    Protocol type: IP (0x0800)
    Hardware size: 6
    Protocol size: 4
    Opcode: request (0x0001)
    [Is gratuitous: False]
    Sender MAC address: IntelCor_aa:aa:aa (aa:aa:aa:aa:aa:aa)
    Sender IP address: (
    Target MAC address: 00:00:00_00:00:00 (00:00:00:00:00:00)
    Target IP address: (

Here the sender's mac address is mine(Here I have hiden my mac address). target IP is mine. Why my machine is sending ARP request to itself? I found 3 packets of this type. There was no ARP reply for these packets. Can anybody explain me why it is? (My operating system is windows-7. I am directly connected to a wifi modem. I got these packets as soon as I started my connection.)

I want one suggestion also. many places I read that RFC's are enough for study about protocols. I studied the RFC 826 on ARP. I personally feel that is not enough at all. Any suggestion regarding this? Is there more then 1 RFC for a protocol? I want to study about the protocols in very detail. Can anybody guide me for this? Thanks in advance.

2 Answers 2


This behavior is a very good way of finding a potential duplicate IP.

If your computer gets no answer, then it is the only one with that IP. If your computer gets an answer, there is another computer with the same IP which is a problem obviously.

Concerning RFCs, I find them horrible to read. I only use them for reference concerning specific problems. I have probably read just one from start to finish. The rest I read bits by bits. IMO, I find that the best way to learn about something is to pick up the O'Reilly or similar paper book and read it.

There can be more then one RFC for a single protocol. For example IPv6 has 10 different RFC just concerning transition mechanisms from IPv4 to v6. There are many others for such things as neighbor discovery. SCTP is covered by 4 RFC also.

  • This is the main reason for generating those packets or this is just one of the benefits? Is this behavior in compliance with any standard?
    – user58859
    Jan 7, 2011 at 14:15
  • I am thinking about going for "tcp/ip illustrated" instead of rfc's but I am also interested in programming aspects of the protocols which is not covered in "tcp/ip illustrated". So am trying to find something better.
    – user58859
    Jan 7, 2011 at 14:22
  • Yes I think this is is main reason. I don't see why this behavior would be breaking any standard. I won't be able to help you with the programming aspects, sorry. Jan 7, 2011 at 14:31
  • 1
    RFCs vary a lot in quality. i'm sure not the only one that misses Jon Postel's
    – Javier
    Jan 7, 2011 at 14:42

This is standard behavior to prevent IP conflicts. It is dicussed in RFC 5227 IPv4 Address Conflict Detection. It also allows routers and neighbors to update their ARP tables so they can communicate with your computer.

By asking who has an IP address it is possible to determine if the IP address is in use. This allows the computer to at least log the existence of a conflict if one exists.

It is this mechanism that allows a computer to use automatic IP address configuration to work using the address block. Computers generate an address in this range, and then use APR to see if it available. If not they try other addresses until they find one available. As the networks are usually small and the address range covers over 65000 addresses, they can find an address quickly.

The arpwatch utility builds a database based on the arp messages which can be used to notify administrators if address are in conflict, or are being moved to new hardware.

  • Thanks for the answer. As soon as I cam to know that there can be more then one RFC for a protocol from the above answer by Antoine Benkemoun, I studied the RFC 5227 and 5494. Now I understood everything.
    – user58859
    Jan 7, 2011 at 18:14
  • Note about arpwatch: if used in DHCP environments, will flag every change in DHCP address in the logs - resulting in a huge amount of noise for very little signal.
    – Mei
    Feb 16, 2012 at 1:07
  • In many DHCP environments addresses are effectively static, and I have used it with little noise in such environments. However, it is a good idea not to generate warnings on guest network ranges. Arpwatch can be configured appropriately.
    – BillThor
    Feb 17, 2012 at 0:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .