Resolve the next hop, then wrap the packet.

The laptop already has a usable lease for 192.0.2.23/24. The subnet mask lets it distinguish an on-link destination from an off-link destination. For 192.0.2.42 on the same /24 network, the next hop is the peer itself. For remote 203.0.113.80, this example chooses the default gateway at 192.0.2.1. The laptop asks ARP for the chosen next hop, not for a MAC address somewhere across the Internet.

When the gateway replies, the laptop stores 192.0.2.1 at 02:00:00:00:00:01 in its ARP cache. The first IPv4 packet is then enclosed in an Ethernet frame addressed to that MAC. Inside the frame, its IP destination remains 203.0.113.80. Later router forwarding would create another link-layer frame. This run stops at first-hop receipt.

The switch maps each source MAC to its ingress port from frames it receives. Its forwarding table does not configure the client and does not fill the client’s ARP cache. In the guided ARP run, broadcast copies go to every other LAN port. The switch sends a later unicast frame only to the port where it learned the destination MAC. If the switch has no entry for the destination MAC, it floods the frame, even when the sender knows that MAC. The ARP workbench explores unknown unicast and independent host caches in more depth.

With a valid lease and a current ARP cache entry for the next hop, the laptop sends a later packet without repeating DISCOVER, OFFER, REQUEST, ACK, or ARP. Lease renewal is a separate exchange later in the lease. A valid lease with an expired ARP entry needs resolution again. If the gateway stays silent, the client can retain valid IPv4 settings while its packet remains queued.

A cable gives you a link. DHCP supplies configuration.

Before that lease existed, the laptop had an Ethernet MAC address and no usable IPv4 configuration. It broadcasts DHCPDISCOVER from 0.0.0.0, using UDP source port 68 and destination port 67. A server proposes 192.0.2.23 in DHCPOFFER. The client selects that offer with DHCPREQUEST. The server commits the lease and returns DHCPACK. The acronym DORA names those four message types.

An offer is a proposal. An ACK has different evidence boundaries: the server knows the lease it committed before the laptop receives the message. This example supplies a /24 subnet mask, gateway 192.0.2.1, DNS server 192.0.2.53, and a 3600-second lease. Receiving those settings does not prove that the gateway or DNS server is reachable.

The client in this example sets the DHCP BROADCAST flag, so the initial offers and ACKs also use Ethernet and IPv4 broadcast destinations. Clients able to receive unicast before configuration can use a different reply path. This lesson models one server on one Ethernet LAN, without a DHCP relay.

Check an address before using it.

This client follows RFC 5227 address conflict detection. It broadcasts three ARP probes with sender IPv4 address 0.0.0.0 and target IPv4 address 192.0.2.23. The zero sender address avoids claiming the proposed address prematurely. ARP travels directly in an Ethernet frame with EtherType 0x0806. It has no enclosing IPv4 or UDP header.

If a conflicting ARP response arrives, the laptop rejects the address and reports it with DHCPDECLINE. The server marks it unavailable when the report arrives. In the successful run, the probe window stays quiet. The laptop then sends two ARP announcements with sender and target IPv4 addresses both 192.0.2.23. It may use the address immediately after sending the first announcement.

The animation compresses randomized probe delays and the wait before announcement. Initial silence is a bounded check, not proof that a conflict can never occur. Real hosts also detect conflicts while using an address. Ordinary DHCP and ARP here provide no authenticated proof of device identity.