In my IPv6 classes, I always teach the basic IPv6 messages as seen on the wire. There’s so much new stuff, such as Router Advertisements, Duplicate Address Detections, Neighbour Solicitations, and so on. Therefore, I’m using a rather simple packet capture showing the starting process of a client getting its addresses.

For the last 10 years, I used this capture, which I took on a Knoppix Linux along with a German Speedport router, in which SLAAC was used for getting the addresses. However, it turned out that in enterprise-grade networks, stateful DHCPv6 is used more commonly. Hence, I did it again and captured the very first IPv6 messages as seen on an IPv6 node, but this time on a Windows 11 PC and a Debian 13, along with stateful DHCPv6.

The Packet Captures

My testbed consists of the following components:

• Windows 11 Version 25H2 (Build 26200.7462)
• Raspberry Pi 3 with Debian GNU/Linux 13 (trixie), Kernel 6.12.62+rpt-rpi-v8
• Palo Alto Networks firewall PA-440 with PAN-OS 11.1.10-h10 as the layer 3 gateway and DHCPv6 relay
• Infoblox Grid with NIOS 9.0.7, acting as the DHCPv6 server to which the Palo relays. The GUA addresses 2a00:6020:ad0b:83::/48 are out of a residential ISP connection (Deutsche Glasfaser) here in Germany. RFC 1918 for legacy IP. (Details about DHCPv6 relaying are here.)

To avoid unnecessary packets, only those clients were present on this VLAN. I captured with a real TAP, the ProfiShark, in between the switch (port A) and the clients (port B), starting *before* the LAN cables were plugged in.

I did those captures with the Windows machine (was powered up, but I plugged in and out the network cable), and then with the the Ubuntu machine, which I booted up and shut down. In both cases, I also did the following simple tasks to have some upper-layer packets in there.:

• ping -c 4 -6 weberblog.net
• ping -c 4 -4 weberblog.net
• nslookup/host securityasapodcast.de
• firefox/lynx http://ip.webernetz.net
• firefox/lynx https://ip-only.webernetz.net

Here are the capture files. Feel free to download and use them for whatever you need. (Please link back to this post if used. Thanks.) Those *.pcapng.gz files can be opened directly in Wireshark. And, of course, those packets are part of the Ultimate PCAP.

–> IPv6 Address Assignment DHCPv6 Windows.pcapng.gz <–
–> IPv6 Address Assignment DHCPv6 Linux.pcapng.gz <–

And since I was on it anyway, I did some new captures for the classical SLAAC address assignment, too. That is: RA with prefix information along with the RDNSS option:

–> IPv6 Address Assignment SLAAC Windows.pcapng.gz <–
–> IPv6 Address Assignment SLAAC Linux.pcapng.gz <–

Packets you can find within those trace files:

• Router Solicitations aka ICMPv6 type 133
• Router Advertisements aka ICMPv6 type 134 (M-flag set, no prefix; respectively prefix information and A-flag)
• Duplicate Address Detection (DAD) aka ICMPv6 type 135, sent from the unspecified address ::
• Neighbour Solicitation & Advertisement, types 135 and 136
• Multicast Listener stuff
• Stateful DHCPv6 (via relay on the Palo, only on the DHCPv6 captures)
• DNS queries
• Ping aka ICMP/ICMPv6 echo-request and echo-reply
• DHCP for legacy IP
• ARP for legacy IP

Wiresharking IPv6 –> Coloring Rules

Please note that I’m heavily relying on colouring rules in order to distinguish all those ICMPv6-based neighbour discovery protocol (NDP) messages, which are: RS/RA, NS/NA, and DAD. Furthermore, the MLD messages, which are not really of interest, are kind of hidden, since I am using a rule of green foreground with white background for them. Refer to these first four lines:

Here’s a side-by-side comparison of the *same* packets without (left) and with (right) my colouring rules:

Looking at the Startup Process

Since a picture is worth a thousand words, here are some of the bootup process from Windows with DHCPv6:

Some Notes

• Neither operating system sends Duplicate Address Detection messages for its link-local addresses, but only for their GUAs. Even though I plugged in the network cable again and again, that is, the capture process always started at the very beginning of the NIC being live on the network. Is this a current best practice I’m not aware of?
• Windows *always* sends DHCPv6 SOLICIT messages, even if the RA does not have the M-flag set, or even if no RA was received at all. Be careful in situations where both SLAAC and M-flag are used! (Not recommended anyway.)
• Quite interesting is the Internet Protocol that Windows/Linux are using for querying the recursive DNS server:
  • SLAAC with RDNSS: Windows IPv4 🟡, Linux IPv4 🟡
  • Stateful DHCPv6: Windows IPv6 ✅, Linux still IPv4 ❌ (WHY?!?!?)
  • That is: Within Dual-Stack environments, IPv6 is not used for reaching the recursive DNS server in many situations. I would have expected it to behave differently. At least for the stateful DHCPv6 part, IPv6 should be used to reach the RDNS. Maybe the stub resolver on my Linux machine behaves differently? Or is it related to latency?
• Windows does not send any Multicast Listener Reports at all. Linux does. (I don’t see any advantages of those MLDs anyway, since almost all layer 2 switches I know don’t leverage multicast snooping by default.)
• When you move a Windows PC into a new Layer 3 network, it initially assumes it is still in the previous one. You can see this as it requests the old IPv4 address via DHCP or tries to use the old IPv6 addresses via NDP. To make matters more complicated, in my two test VLANs, the Palo Alto Networks firewall (default gateway) always uses the exact same IPv6 link-local address, fe80::3efa:30ff:fe04:9114.
• I omitted many other chatty packets that were sent during the first seconds of a connected network, e.g.: NTP, LLMNR, NBNS, MDNS, IGMP, SSDP. Those are all sent for various reasons (that I don’t know) from Windows. That is: While my proposed PCAPs show all packets relevant to IPv6 and legacy IP address assignment, it does NOT show all possible name resolution and network reconnaissance attempts from Windows itself.

For the sake of completeness, here are some screenshots of how I set up the layer 3 interfaces on the Palo. (Note that I initially configured a third testbed with “stateless DHCPv6”, hence the O-flag. But since this is not a relevant scenario anymore, as all major operating systems have RDNSS implemented, I did not follow up on those captures.)

Soli Deo Gloria!

Photo by Dayne Topkin on Unsplash.