Nmap can scan IPv6 networks just as effectively as IPv4, but it uses different underlying mechanisms and has some unique considerations.
Let’s see Nmap in action with IPv6. Imagine you have a local IPv6 network range, perhaps fe80::/64, and you want to see what’s alive and what services are running.
sudo nmap -6 -sT -p 22,80,443 fe80::1/64
This command tells Nmap to:
-6: Enable IPv6 scanning.-sT: Perform a TCP connect scan. This is often a good default for IPv6 as it’s less likely to be blocked by firewalls than some stealthier methods.-p 22,80,443: Scan only for SSH, HTTP, and HTTPS ports.fe80::1/64: The target IPv6 network.fe80::/64is a link-local address range, meaning it’s only valid on your local network segment.
The output might look something like this if you have a host at fe80::a1b2:c3d4:e5f6:7890 running SSH:
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-27 10:00 EDT
Nmap scan report for fe80::a1b2:c3d4:e5f6:7890
Host is up (0.00050s latency).
Not shown: 997 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp closed http
443/tcp closed https
Nmap done: 1 IP address (1 host up) scanned in 2.34 seconds
This tells you that the host fe80::a1b2:c3d4:e5f6:7890 is alive, and its SSH service is accessible.
The core problem Nmap’s IPv6 scanning solves is bridging the gap between the traditional IPv4-centric network tools and the growing reality of IPv6 deployment. Many network administrators are still more comfortable with IPv4, and finding and enumerating devices on an IPv6 network can be challenging without the right tools. Nmap, with its -6 flag, provides a familiar interface for this task.
Internally, Nmap uses the operating system’s IPv6 stack to craft and send packets. For TCP scans (-sT), it performs a full TCP three-way handshake. For UDP scans (-sU), it sends UDP packets and looks for ICMPv6 "Port Unreachable" messages to determine if a port is closed. If no response is received, the port is considered open or filtered. Nmap also supports other scan types like SYN scans (-sS), but these often require raw socket access, which can be more complex with IPv6 and may have varying levels of OS support.
One of the key differences from IPv4 scanning is how you specify targets. IPv6 addresses are much longer and use hexadecimal notation with colons. You’ll often see addresses like 2001:db8::1 or fe80::1234:5678:9abc:def0. When scanning a subnet, you’ll use CIDR notation, similar to IPv4, but with the longer addresses, e.g., 2001:db8:abcd:1234::/64.
The challenge with IPv6 scanning often lies in the network configuration itself. Unlike IPv4, where DHCP is ubiquitous, IPv6 relies heavily on Stateless Address Autoconfiguration (SLAAC) and DHCPv6. This means hosts can have multiple IPv6 addresses: a link-local address (starting with fe80::), and one or more global unicast addresses assigned via SLAAC or DHCPv6. Nmap will attempt to discover and scan all of them if they are reachable.
When Nmap sends a probe to an IPv6 address and receives no response, it doesn’t automatically mean the host is down. It could be that the probe was sent to the wrong address, or that a firewall is silently dropping the packets. This is where techniques like ICMPv6 echo requests (ping) become crucial, though firewalls can also block these. Nmap’s -PE option (ICMP echo request) can be used with IPv6, but its effectiveness depends on network policies.
The surprise is that Nmap’s IPv6 scanning often works out of the box with very few changes to your existing IPv4 scanning habits, provided your operating system has decent IPv6 support and your network is properly configured. The complexity isn’t in Nmap itself but in understanding the IPv6 addressing scheme and the nuances of routing and firewalling in an IPv6 environment.
The next hurdle you’ll likely encounter is performing more advanced IPv6 discovery, such as mapping network topology or identifying devices that are only listening on specific IPv6 interfaces.