Why can a worm sweep a local /24 but not generate random addresses on an IPv6 /64?

## Selection is a search problem Code cannot attack an address it never produces. Every self-spreading program therefore carries a **next-host selection** strategy, and the strategy's quality is measured in one currency: attempts spent per live host found. Two strategies dominate, and they differ by many orders of magnitude depending on the address family. ## Sweeping the local subnet An infected device knows its own interface configuration: address and prefix length. On a flat office or branch segment that is typically a /24 - 254 usable addresses. Sweeping every one of them costs a few hundred attempts and finds essentially all the live neighbours, because a real segment packs printers, badge controllers, cameras and terminals into a range sized for exactly that. The device also holds a **free list of confirmed-live neighbours**: entries it has already resolved while doing ordinary work. Those are better than swept addresses, because each one is known to exist and to be answering. ```text infected shop-floor terminal, interface eth0 inet 10.42.7.34/24 -> 254 usable neighbour addresses inet6 2001:db8:7::9c1f/64 -> 2^64 addresses in the prefix ARP cache (IPv4 neighbours already resolved) 10.42.7.1 00:1b:21:aa:bb:01 10.42.7.19 00:80:77:3c:12:9e 10.42.7.52 00:0f:7c:44:aa:31 IPv6 neighbour cache fe80::21b:21ff:feaa:bb01 REACHABLE ... ``` That is a hot list of known-live hosts plus a trivially enumerable range, handed over by the device itself. ## Generating random addresses To reach beyond the segment, the historical technique is to generate 32-bit addresses at random and try them. IPv4 is small enough that this works despite most draws hitting space that is unallocated, unrouted or filtered: the code just makes attempts fast and accepts a low hit rate. Implementations usually bias the draw - a share of attempts inside the local /16 or /24, the rest global - precisely because the local range pays back so much better per attempt. ## Why the same idea collapses on IPv6 A standard IPv6 interface subnet is a **/64**: 2 to the power 64 addresses, about 18 quintillion. Put 300 devices in it and the probability that one random draw lands on a live address is roughly 300 divided by 1.8 times 10 to the power 19 - about one in 10 to the power 17. At a million attempts per second you would expect to wait longer than the age of the universe for a single hit. Random generation is not slow here; it is useless. Addresses are also not uniformly placed within the /64, which cuts both ways. Interface identifiers derived from a MAC address (the EUI-64 form, recognisable by the `ff:fe` in the middle - note how `00:1b:21:aa:bb:01` above becomes `fe80::21b:21ff:feaa:bb01`) concentrate the search onto vendor prefixes, and manually numbered hosts cluster at low values like `::1`, `::2`, `::10`. Privacy addressing scatters them back across the whole range. ## What replaces generation On an IPv6 segment a spreader shifts from guessing to **reading what the device already knows**: - the neighbour cache, which lists neighbours confirmed live, - the prefix learned from router advertisements, which at least bounds the search, - link-local all-nodes multicast, `ff02::1`, which every node on the link is required to join, so a single message reaches all of them, - names it can resolve, and addresses sitting in configuration files, inventories or peer lists on the host. ## The conclusion to state out loud The right takeaway is **not** "IPv6 stops worms". It is that address-space density decides which selection strategy is viable, and on a /64 the viable strategies are all local-knowledge strategies. A segment-local spreader loses nothing - the neighbour cache and multicast reach exactly the flat segment it wanted - while the internet-wide random scan that IPv4 permitted has no IPv6 equivalent. If a candidate answers this with "IPv6 is too big to scan, so it is safe", push them on multicast and the neighbour cache and watch the claim fall over.