Code:
# The first non-ipv6 packet.
# The client, 00:08:c7:77:9a:a2, broadcasts a DHCP request across the
# entire network segment.
10:14:29.584192 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:08:c7:77:9a:a2 (oui Unknown), length 300
# Our DHCP server, 00:23:54:d9:7f, gives a reply targeted specifically at
# 00:08:c7:77:9a:a2, to tell it to become IP 192.168.0.131.
# There may also be info such as default gateway, DNS servers,
# and PXE boot paths embedded in the reply.
10:14:29.584332 00:23:54:d9:7f:4e (oui Unknown) > 00:08:c7:77:9a:a2 (oui Unknown), ethertype IPv4 (0x0800), length 342: xxxx.xxxx.xxx.bootps > 192.168.0.131.bootpc: BOOTP/DHCP, Reply, length 300
# Here the client requests again for good measure, and gets the same reply.
10:14:29.586406 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 351: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:08:c7:77:9a:a2 (oui Unknown), length 309
10:14:29.587720 00:23:54:d9:7f:4e (oui Unknown) > 00:08:c7:77:9a:a2 (oui Unknown), ethertype IPv4 (0x0800), length 342: xxxx.xxxx.xxx.bootps > 192.168.0.131.bootpc: BOOTP/DHCP, Reply, length 300
# Here the client, 00:08:c7:77:9a:a2, broadcasts an ARP who-has request
# across the segment to check if the DHCP server has given us a boneheaded
# occupied IP address. Some DHCP clients, like windows ones, don't seem to
# check this, causing IP address conflicts should the DHCP server get
# rebooted.
#
# The downside to this doublethink is time wasted. A process that
# hypothetically could be nearly instant can take many seconds when the
# client is paranoid.
10:14:29.590811 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.131 tell 0.0.0.0
10:14:30.748326 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.131 tell 0.0.0.0
10:14:32.670568 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.131 tell 0.0.0.0
# About 5 seconds after the DHCP server sent its DHCP reply to the client,
# it sends an ARP request directly to the client's MAC address asking what
# IP address it has.
10:14:34.586710 00:23:54:d9:7f:4e (oui Unknown) > 00:08:c7:77:9a:a2 (oui Unknown), ethertype ARP (0x0806), length 42: arp who-has 192.168.0.131 tell xxx.xxx.xxx.xxx
# ...and does so again a second later. The client missed the last one, busy contemplating the
# mysteries of life or something.
10:14:35.586665 00:23:54:d9:7f:4e (oui Unknown) > 00:08:c7:77:9a:a2 (oui Unknown), ethertype ARP (0x0806), length 42: arp who-has 192.168.0.131 tell xxxx.xxxx.xxx
# The client sends an ARP reply directed to the DHCP server finally.
10:14:35.586921 00:08:c7:77:9a:a2 (oui Unknown) > 00:23:54:d9:7f:4e (oui Unknown), ethertype ARP (0x0806), length 60: arp reply 192.168.0.131 is-at 00:08:c7:77:9a:a2 (oui Unknown)
# This particular interface on the client is configured for two IP addresses:
# one gets set by DHCP, the other is statically set to 192.168.0.2.
#
# To be polite, the client broadcasts an ARP request asking if anyone else
# has 192.168.0.2.
10:14:36.023579 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.2 (Broadcast) tell 0.0.0.0
10:14:36.866266 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.131 tell 192.168.0.131
# After one second, having received no answer, it asks again.
10:14:37.023771 00:08:c7:77:9a:a2 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: arp who-has 192.168.0.2 (Broadcast) tell 0.0.0.0
# After here ARP requests are still sent to/from it from time to time but the interface is obviously already up.