Tag Archive: IPv6

Broadcast pings: do they work?

I’ve often seen discussions of ‘how to find devices in the network using pings’. A ping sweep is easiest, but some people claim that a simple ping to the subnet broadcast address will make all devices respond. I decided to test this out for myself and see what happened.

I created a subnet with as many different devices as I could get my hand on at the time. The devices were the following:
– Windows 7 physical machine
– Windows XP physical machine
– Windows Server 2008 R2 virtual machine
– Fedora 15 virtual machine
– Vyatta 6.1 virtual machine
– Cisco 2611 router
– Cisco VG200 Voice Gateway
– Two Cisco 3560 Layer 3 switches
– A Linksys router with DD-WRT firmware
– The ISP-provided gateway: a Motorola with NAT
– Cisco 7912 IP Phone
– And finally, one iPod, for a total of 12 devices having an IP address.

I ran Wireshark on the physical machines (Windows 7 and Windows XP) from which I was going to originate the pings. I also did pings from some of the Cisco devices. Contrary to Windows, IOS will list all replies received when sending to a broadcast address. All devices received an IP address in the range, the pings were done to

I did several tests and also changed IP addresses several times between tests to ensure ARPs were sent around the network, which made it easier to follow the captures on Wireshark. The results showed a clear separation between network devices and end devices: the Cisco gear (with the exception of the IP Phone) would respond to broadcast pings, as well as the DD-WRT. All other devices wouldn’t respond to broadcast pings. The Vyatta and the ISP gateway are also network devices, but I have no control over the gateway, and the Vyatta is actually nothing more than a stripped-down Linux and thus may react as an end device in this regard. To be sure I didn’t make a mistake, I did unicast pings after this to the addresses that didn’t respond, and they all reacted fine. No firewall issues here.

There’s still a difference between a ping sweep and a broadcast ping, even if just done towards network devices: a ping sweep will trigger ARP requests for each address, to which devices will respond if they have the address, whether ICMP pings are blocked or not. So after a ping sweep, just doing ‘arp -a’ in the Windows command line reveals all managed network devices.

That answers one question, but what about IPv6? Are things different there? A ping sweep is nearly impossible. A common /64 subnet is 1.8×10^19 addresses, with EUI-64 (see a perfect explanation about EUI-64 on Packetlife.net) you can exclude some addresses, leaving ‘just’ 2.8×10^14 possible combinations. Multicast pings would be the only feasible option to scan a subnet. Note that I say multicast, as IPv6 has no concept of broadcast. Since most of my devices do not have IPv6 support for the moment (I’m planning on upgrading them in the future), I’m left with the Vyatta, Windows 7, Windows Server, and Fedora for this test. But the test results are similar to IPv4: a ping to FF02::1 (‘all nodes’ multicast) does not give a single reply, but a ping to FF02::2 (‘all routers’ multicast) gives a reply from the Vyatta, which is indeed configured for IPv6 routing. So with limited testing I can conclude for now that it’s also just network devices that respond to ping in IPv6.

To return to the original claim that a broadcast ping will reveal all devices in a given subnet: the conclusion is that this only goes for network devices, and not for end devices. It’s probably not an effective way to quickly map a subnet in everyday life.


Another interesting article about IPv6 on Cisco’s blog site today, this time from Michael Sanchez. It’s about the secure transition from IPv4 to IPv6.

While not stated explicitly in the blog, it mentions one of the reasons why some companies are hesitant to implement IPv6: they are unfamiliar with the security implications. Companies generally see migrating to IPv6 as a slow task that takes time, testing, and money. Unfortunately, there’s not much argumentation against this: while for smaller companies the migration can be done quite quickly, a full migration of a large company takes time.

Security during the transition does indeed become complex as Michael mentions: dual stack means double the amount of firewall rules, as well as the added risk of tunnels. To give just one example: NAT-PT can cause serious problems, even if deprecated.

Most modern computers have IPv6 enabled by default. This may cause a man-in-the-middle attack when someone sets up a rogue IPv6 router on a subnet with NAT-PT (which I’ve been able to do with as little as a small virtual machine, no physical evidence). Most modern operating systems (especially Windows) prefer IPv6 over IPv4 in a dual stack environment and will sent all data to the rogue gateway, who will then pass the data on as IPv4 using NAT-PT, but scanning all data in the process.

Again a small word of advice to the companies that sell firewalls (both appliance and software): try researching and promoting the IPv6 side of the story a bit more. If people see firewalls, IDS and IPS systems that can scan IPv6 traffic, maybe things will be put into motion a bit faster. Solutions for IPv6 already exist but they are barely marketed, giving the impression the IPv6 internetwork is “The Wild West” (a quote by my CCNA Teacher).

What are your thoughts? Let me know in the comments.

IPv6 thoughts.

Despite IPv6 being announced as the successor of IPv4, at times little is done to give it the chance to be deployed properly. I noticed that most standard Cisco IOSes still don’t support it – No support in the 3560 IP Basic and even IP Services IOS.
Update: 28/01/2012: 3560 does support it, see SDM templates.

Most consumer routers these days also don’t offer support for IPv6 yet (but I suppose firmware updates in the future could solve this, and some high end models are starting to give support).

It does make one wonder: a protocol that has been around for almost 13 years now, clearly designed to counter an address shortage, yet still little is done to help building out infrastructure for it in everyday live. The good news is that Microsoft’s and Apple’s operating systems have IPv6 support by default now, with Linux already supporting it for years, so end-user devices are mostly ready for it. It’s everything between all those end devices that’s the problem (except for Layer 2 switches of course).

A second thing to wonder about is the whole SLAAC/DHCPv6 issue: IPv6 came with this nice StateLess Address Auto Configuration mechanism so every device could find it’s IP address automatically. It even finds the subnet’s gateway. But it doesn’t give a DNS server: for that you need a DHCPv6 server, which, surprise surprise, does not give a gateway.

From a network engineer’s point of view this is somewhat understandable: the gateway is something you need at Layer 3, while DNS can be classified with the rest of the DHCP options (TFTP, NTP,…) under Layer 7 services. But it doesn’t make things easier for an end-user. To date this means that a consumer router will have to run both SLAAC and DHCPv6. There are also differences between how Windows, OSX and Linux treat the information they receive: some operating systems ignore the ‘Managed address configuration’ or ‘Other configuration’ flag, others don’t. Also, most DHCPv6 servers I tested to date did not give the expected results: Cisco’s implementation in their IOSes did not do anything (though the new 15.x IOS may have solved this, or I simply did things wrong), Vyatta’s DHCPv6 server does not get formatted properly in their configuration files and does nothing as well (a known bug still in research). Windows Server 2008 does give a working DHCPv6 server, but it requires a reboot for each change I’ve noticed so far.

All in all, IPv6 still seems to have a long road ahead.