nnection activation. Scanning of the address range, or rather a /64 IPv6 prefix, for possible victims is another concern. It is often naively bypassed, stating that the IPv6 address's IID number space is SO huge (264 possibilities) that off-link initiated scanning attempts are doomed to fail. However, in practice the IID space is much smaller [173]. If the scanning attack is targeted at a specific brand of devices, then the Organizationally Unique Identifier (OUI) part of the EUI-64 can be fixed (that is 24 bits less to scan). If the target is expected to have an Ethernet network interface, then another 16 bits of the IEEE 48 bit MAC address derived from modified EUI-64 is fixed (the 0xfffe part in the middle of the EUI-64). Now we are down to 24 bits of number space to scan, which does not sound that bad anymore. Similarly, if the address is manually configured or the end host is possibly dual-stacked, guessing the address has higher probability due the laziness of network management personnel. It is surprisingly common to just embed small numbers that fit into the last octet of the IID (like 69) or the service port number as the IPv6 IID. Another common practice is to use the IPv4 address of the end host or some hexadecimal combination forming a readable word as the IPv6 IID (take 2001: db8 192.0.2.1 and 2001 db8 : abad: cafe as examples). For the latter, manually configured IIDs, stable privacy addresses [172] or 'human-safe' Cryptographically Generated Addresses (CGAs) [174] work as a good solution to avoid predictable addresses. Another remote IPv6 address scanning side effect is the unnecessary address resolution performed by the first-hop router on the link trying to resolve the link-layer address of the (bogus) IPv6 destination address. This is known as a Denial of Service (DoS) attack, which attempts to fill the ND cache of the router [163]. Rate limiting of address resolution or filtering incoming packets with 'impossible' IID ranges in their destination address are a few of the approaches to mitigate t