How a device joins a network

You open a laptop, it connects to the Wi-Fi, and a few seconds later web pages load. In those few seconds the laptop has solved several problems. At first it had no IP address and did not know how large the local network is, which device leads to the rest of the internet, or which servers answer DNS questions. And for every packet it sends on the local network, it must also know the hardware address of the device that should receive it.

This article follows a device through those first seconds, first with IPv4, where DHCP and ARP do the work, and then with IPv6, where router advertisements, SLAAC, Neighbor Discovery and DHCPv6 take over. The hardware addresses in the examples are reserved for documentation (RFC 9542), and so is the IPv6 prefix 2001:db8::/32 (RFC 3849).

What a device needs

The default router, often called the gateway, is where a device sends every packet whose destination is not on the local network. The hardware address, or MAC address, is the 48-bit address of a network card that Ethernet and Wi-Fi use to deliver frames on the local link.

DHCP: asking for an address

A device that has just connected has no address and does not know whom to ask. The Dynamic Host Configuration Protocol (DHCP, RFC 2131) solves this by broadcasting. DHCP is based on the older Bootstrap Protocol (BOOTP, RFC 951) and runs over UDP: clients send to port 67, servers answer to port 68. In a home, the DHCP server is often built into the router.

Getting an address takes four messages:

1. Discover. The client broadcasts a DHCPDISCOVER to the whole local network. It has no address yet, so it sends from 0.0.0.0, which RFC 1122 allows only while a host is learning its own address, to the broadcast address 255.255.255.255.
2. Offer. Each DHCP server that hears it may answer with a DHCPOFFER containing a free address and other settings.
3. Request. The client picks one offer and broadcasts a DHCPREQUEST that names the chosen server. Because it is a broadcast, the other servers learn that their offers were declined.
4. Acknowledge. The chosen server records the assignment and confirms it with a DHCPACK.

The settings travel as numbered options (RFC 2132). The most important are:

Before using the address, the client should make a final check, for example with ARP (see below). If another device already uses it, the client sends a DHCPDECLINE and starts over. On networks with many subnets, a relay agent on each subnet passes the broadcasts on to a central DHCP server.

Leases: addresses on loan

A DHCP address is not given forever but leased for a limited time, so that addresses of devices that have left can be reused. The client must renew the lease before it runs out, using two timers from RFC 2131:

• At T1, by default half of the lease, the client asks the server that gave it the address to extend the lease, with a DHCPREQUEST sent directly to that server.
• If that server does not answer by T2, by default 87.5% of the lease, the client broadcasts its request so that any server can extend it.
• If the lease expires without an answer, the client must stop using the address and start over.

A device that leaves the network politely can return its address early with a DHCPRELEASE.

ARP: from IP address to hardware address

Even with an address, a device cannot yet send a packet to its router. Ethernet and Wi-Fi deliver frames to hardware addresses, not IP addresses, so the device must find out which hardware address belongs to 192.168.1.1. That is the job of the Address Resolution Protocol (ARP), defined in RFC 826 in November 1982 and still in use for IPv4 today.

1. The laptop broadcasts an ARP request to every device on the local network: “Who has 192.168.1.1? Tell 192.168.1.20 at 00:00:5e:00:53:01.”
2. Only the device with that address answers, with an ARP reply sent directly to the laptop: “192.168.1.1 is at 00:00:5e:00:53:fe.”
3. The laptop stores the answer in its ARP cache and uses it for the following packets.

The request also carries the sender’s own addresses, and RFC 826 has the receiver store them right away, on the assumption that “if A has some reason to talk to B, then B will probably have some reason to talk to A.” The router can then reply without asking in return.

RFC 5227 adds address conflict detection: before using a new address, a device sends three ARP probes, requests asking for its own new address with the sender address set to all zeros, so that no other device’s cache is changed. If nobody answers, it announces the address twice with ARP announcements.

ARP has no protection at all. As RFC 5227 notes, “it is easy for a host to answer all ARP Requests with Replies giving its own hardware address, thereby claiming ownership of every address on the network.” Any device on the local network can redirect traffic this way, which is one reason why untrusted networks need encryption such as TLS.

IPv6: the network describes itself

IPv6 takes a different approach. Instead of asking a server for everything, a device mostly learns from the network’s routers and builds its addresses itself. Neighbor Discovery (RFC 4861) provides the messages, all of them ICMPv6 messages:

RFC 4861 describes Neighbor Discovery as the counterpart of three IPv4 mechanisms: ARP, ICMP router discovery and ICMP redirects.

SLAAC: a device configures itself

Stateless Address Autoconfiguration (SLAAC, RFC 4862) builds addresses without any server:

1. Link-local address. The device first creates an address that is valid only on the local link, by appending a 64-bit interface identifier to the prefix fe80::/64 (RFC 4291).
2. Duplicate address detection. Before using the address, the device sends a Neighbor Solicitation asking for it. If another device answers, the address is taken.
3. Router solicitation. Routers send advertisements regularly, but the device does not want to wait, so it asks for one with a Router Solicitation to the all-routers group ff02::2.
4. Router advertisement. A router answers with the network’s prefix, for example 2001:db8:1:1::/64, a flag allowing devices to build addresses from it, and two lifetimes that say how long such addresses remain preferred and valid. It also carries the router’s own hardware address, so no extra lookup is needed.
5. Global address. The device combines the prefix with an interface identifier, checks this address for duplicates too, and is ready.

Where does the interface identifier come from? Older systems derived it from the hardware address, which made a device recognizable on every network it visited. RFC 8064 now recommends against that and recommends the method of RFC 7217, which produces an identifier that is “stable within each subnet” but changes when the device moves to another network. For outgoing connections, devices can also use temporary addresses with random identifiers that change over time (RFC 8981), which limits how easily their activity can be linked together.

Router advertisements can also carry the addresses of DNS servers (RFC 8106), so a device can be fully configured without any DHCP at all.

Neighbor Discovery instead of ARP

To find a neighbor’s hardware address, an IPv6 device sends a Neighbor Solicitation. Unlike an ARP request, it does not go to everyone. It goes to a solicited-node multicast address, built from the last 24 bits of the address being looked up (RFC 4291):

looking for:              2001:db8:1:1::20
solicited-node address:   ff02::1:ff00:20

Only devices whose addresses end in the same 24 bits listen to that group. RFC 4861 notes that these lookups are “spread” over 16 million (2²⁴) multicast addresses, so the other devices on the link are hardly ever disturbed. The neighbor answers with a Neighbor Advertisement.

Neighbor Discovery also keeps checking: with neighbor unreachability detection, a device notices when a neighbor or router stops responding and can switch to another router. IPv4 has no generally agreed mechanism for this.

DHCPv6: when the network wants control

Some networks, such as company networks, want to assign and record addresses centrally. For them there is DHCPv6, whose current version is RFC 9915 (2026). Two flags in the router advertisement tell devices what to use: M (“managed”) means addresses are available from DHCPv6, and O (“other”) means only other settings, such as DNS servers, are.

DHCPv6 works much like DHCP, with different names and ports (clients listen on UDP port 546, servers on 547). A client sends a Solicit to the multicast group ff02::1:2, which all DHCPv6 servers and relay agents on the link join; servers answer with an Advertise; the client sends a Request; the chosen server confirms with a Reply. With the Rapid Commit option, a Solicit and a Reply are enough. A client that only needs settings sends an Information-request.

DHCPv6 can also hand out whole prefixes, which is called prefix delegation: an internet provider can give a home router a block of IPv6 networks to use inside the home.

Privacy

Joining a network reveals information. DHCP messages can contain a device’s hardware address, host name and other unique identifiers. RFC 7844 notes that these “can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses”, and defines anonymity profiles that tell clients what to leave out.

Key points

• To use a network, a device needs an address, the network size, a default router, DNS servers, and the hardware addresses of its neighbors.
• In IPv4, DHCP provides the settings in four messages: Discover, Offer, Request, Acknowledge. Addresses are leased, renewed at T1 (half the lease) and T2 (87.5%).
• ARP finds the hardware address for an IPv4 address by asking everyone on the link. It has no security of its own.
• In IPv6, routers announce the network’s prefix in router advertisements, and devices build their own addresses with SLAAC, checking first that no one else uses them.
• Neighbor Discovery replaces ARP, using solicited-node multicast so that only likely candidates are asked. DHCPv6 serves networks that want central control and delegates prefixes to home routers.