address resolution protocol | updates closed

this article is based around default installs of windows 95a-xp (nt4 has sp6a) and was tested on a 10mb tcp, static ip, hub connected network. some things will handle differently in other oses, configurations and setups. to read the orginal standard of arp check rfc 826.
in this article nt refers to nt4/2k/xp and 9x refers to 95a/95b/98/98se/me


address resolution protocol(arp) is used before a network transmission. the purpose is to discover whether the two machines can communicate with each other, plus to determine the media access control(mac) address of the remote network card.

mac addresses are a 6 byte network interface card(nic) unique identifier. an example: 00-60-97-fe-ec-66. they are set at nic assembly. the coding is ordered to prevent duplication. the ieee issues nic manufactures with a unique 3 byte prefix, as in the example before: 00-60-97 is assigned to the 3com corporation. some nic manufactures product a lot of cards, more than 16 million, thus some companys have more than one 3 byte prefix. (3com has 16, giving ~268 million unique macs) the register is available here:

finding out what the local nic mac address is

winipcfg.exe (select ndis driver)
nbtstat -a %localnetbiosname% (dosbox)
ipconfig /all (dosbox)
winmsd.exe (network -> transports)
\system information\components\network\adaptor\
\system information\components\network\adaptor\

some nic cards have the mac printed on them or written on by a former owner. with all systems you could view the remote arp table (arp -a) of a machine you have just communicated with or capture some of the machines network traffic.

changing the mac address

mac addresses of some nics can be changed, but remember they were made to be unique for a reason and that some mac addresses are used for broadcasting. two machines of the same mac cannot communicate with each other. other errors may occur with duplicate+ macs.

string value: "networkaddress"="%new_mac_address%" if the card supports mac changes this key will probably already be there as: 000000000000 - change to new one and reboot for possible update.

open device manager, view the properties of the network card from network adaptors. switch to the advanced tab, select network address in the properties list (if available). check the upper radio button and enter a new mac address, fun example: f00baac0ffee - click ok. the mac should be updated, no reboot required.

arp request and reply

suppose desktop wants to communicate directly with server. to build packets it needs an ip address, which it probably already has through netbios broadcasts, and a mac address. although the remote machine's mac is used in broadcasts, netbios does not read at that level. first it would check its own arp table to see if the machine's ip is present, matched with a mac address. if there is no entry, an arp request is broadcast to the network.

arp request: (desktop -> broadcast)

transmission section

-> destination mac address
      unknown thus a broadcast
-> source mac address
-> packet type/frame (=arp)

ips are converted into hex
a.b.c.d = 0xa,0xb,0xc,0xd  -> c0,a8,00,2a -> c0,a8,00,64 -> c0,a8,00,6e
arp data section

-> hardware type (=ethernet)
-> protocol type, required (08,00 dod ip)
-> length of hardware address (mac address)
-> length of protocol address (ipv4)
-> arp type (00,01 request) (00,02 reply)

-> sender's hardware address (mac address)
-> sender's protocol address (ip address)
-> target hardware address (mac address)
      unknown at this point thus blank
-> target protocol address (ip address)

-> padding (ignore)

the broadcast is recieved by all machines on the network, all of which checkout the packet - can they communicate using the protocol specified and is their ip the one stated in the packet? if not, the packet is discarded. if the receiving machines ip and protocol match, the details of the requesting machine will be added to its arp table and a reply sent back with the unknowns added. note: all windows systems will respond to both hardware type = 00,01 (ethernet 10mb) and 00,06 (ieee 802 networks) with hardware type = 00,01.

arp reply: (server -> desktop)

once desktop has recieved this packet the information will be added to its arp table and the two machines can now start to communicate directly with each other. if desktop does not receive this reply, any prior initiated network traffic will timeout and fail.

arp at bootup

arp is also used at startup, to check for ip conflicts. an arp request is broadcast with the target and sender's protocol address set to the ip that the machine is hoping to be. if there is no reply the machine uses that address. if there is a reply the machine will disable its outgoing network traffic for that ip. the remote machine will then do a similar broadcast, probably to check that the new conflicting machine has not used its ip. a message will be displayed on both the machine booting and the machine that the conflict has occured with.

the system has detected a conflict for ip address %ip_address% with the system having hardware address %remote_mac_address%. [the interface has been disabled.]

the section in [] is not displayed on the machine already using the conflicting ip. the nt error message varies slightly. nt also writes an entry to the event log. 9x and nt4 all display this message fairly promptly, however 2k and xp wait about a minute after logon.

at startup 9x will arp request once and wait briefly before starting netbios traffic. (note that sometimes it maynot arp at all)
nt will arp request 3 times at startup (nt4 may only arp twice) and wait alittle longer before starting netbios traffic. the gap between the arp requests is ~1sec.

the waiting time could be used to determine more accurately what the remote os is, however due to variations in machine speed and other process running this probably would not be practical unless benchmarks were done on machines of similar spec.

example: 800mhz mobile pentium with 128mb ram
5 tests were carried out on each os, the following mean averages were found:

95b = 0.768secs | 98 = 0.780secs | 98se = 0.748secs | me = 0.668secs
nt4 = 2.568secs | 2k = 8.680secs | xp = 4.190secs (nt times are from the first arp)

waiting times in 2k and xp booting into safe mode with network support cause varations, ~7secs on 2k and ~10secs in xp. me, 2k and xp system can detect when the network connection is lost, all show a significantly reduced waiting times. me ~0.410secs, 2k ~1.010secs and xp ~2.090secs on reconnection.

manually adding, deleting and viewing the arp table

windows includes a cmd/dosbox program called arp.exe

command: (dosbox)
manually add a static arp entry
arp -s %ip_address% %mac_address%
manually delete an arp entry
arp -d %ip_address%
view the arp table
arp -a


manually add entries:
manually delete entries:
view table:
only an administrator account
only an administrator account
only an administrator account
only an administrator account
only an administrator or a network configuration operators account
only an administrator or a network configuration operators account

delete - nt/95b(the arp entry deletion failed: 87)
add - nt(the arp entry addition failed: 5) and 9x(the arp entry addition failed: 2)

arp entry lifetime and state

arp tables are stored in the ram and are lost at restart/shutdown, but not logoff.
arp tables are lost on standby/suspend in 95a/95b/98, but not in 98se/me/2000/xp
  windows me however has a slight problem on resuming:
  previous and new entries cannot be manually viewed/deleted
  new manual entries cannot be added: the arp entry addition failed: 5
arp tables are not lost on hibernation in 2000/xp

there are two types of entry in an arp table, dynamic and static. when an arp request or arp reply is recieved the information is added to the table. if no further network traffic occurs between the two machines the entry will be automatically removed after 2 minutes. each time a packet is built/sent, the system checks the arp table, if the required ip is present the packet is built/send using the stored mac and the two minute timeout is refreshed at that point. this is true on all windows systems 95a - xp. entries added manually (arp -s) are static and do not timeout. if the network connection is lost on a me/2k/xp system, all dynamic and static arp entries are deleted about 8/9 seconds after disconnection.

arp security

arp is a very trusting protocol. spoofed arp packets will update arp tables. if laptop sent an arp request to desktop with the senders ip set to server's and a phoney mac address, desktop would not be able to communicate with server for a minumum of 2 minutes (unless the entry was manually deleted) such an attack/prank could run through all the ips of the internal network updating the arp entry of a central resource causing it to be inaccessable. spoofed packets would need to be sent with a gap of less than 2 minutes to prevent arp table timeouts. spoofed replies could also be sent to booting systems, effectively disabling their networking. finding the origins of the spoofed packets will probably be difficult as the source mac address can be spoofed also and the packets staggered to prevent "busy" hub lights.

in defense you could: use dhcp to stop spoofed ip conflicts. use a rule based firewall, set to block arp and run a batch file with static arp entries in. problems here would be getting the entries loaded before login if authenticating against a remote system. also some(most?) firewalls do not load quick enough to stop a spoofed ip conflict packet, visnetic by deerfield has an option to block all network traffic when firewall is not running. remember all the machines that you want to communicate with would also have to add static arp entries. unsure about physical protection such as lowlevel firewalls or a decent switch.

more arp

there is also reverse address resolution protocol, whereby the future local ip of a machine can be requested from a rarp server of a known mac address. standard here: - windows systems do not use rarp or include a rarp server, however a third party rarp server program is available for nt here: (scroll down to the bottom)

another addition to arp is inverse address resolution protocol. similar to rarp, but intended to find the remote protocol address from a system of a known mac address. this rfc also mentions some the security issues of arp in general, but does not offer a solution.

last section of 7(.0):

note: as with arp, information learned via inarp may be aged or invalidated under certain circumstances.

also section 8:

this document specifies a functional enhancement to the arp family of protocols, and is subject to the same security constraints that affect arp and similar address resolution protocols. because authentication is not a part of arp, there are known security issues relating to its use (e.g., host impersonation). no additional security mechanisms have been added to the arp family of protocols by this document
you must get permission from the respective author before reproduction