In conclusion: enabling only IPv6 can indeed reduce the probability of being scanned and subjected to automated attacks to some extent, but don't expect it to replace proper security measures such as firewalls, key-based logins, and system hardening. It's more like a low-cost "invisible door" than bulletproof armor. Many people think that the IPv6 address space is ridiculously large, making scanning almost impossible, and therefore inherently secure. This idea is half right, but the reality of network security is often more complex than you imagine.

　　I. What exactly does the terrifyingly large IPv6 address space mean?

　　Let's look at the numbers. The IPv4 address space is 32 bits, totaling approximately 4.2 billion addresses. This number sounds large, but for automated scanning tools, scanning all IPv4 addresses globally with a regular computer and high-speed bandwidth can be completed in about a few hours. Attackers have hundreds or thousands of botnets, making their scanning efficiency even higher. This is why your server, just minutes after going live, can be targeted by various scanners—SSH brute-force attacks, web vulnerability probes, common port scans—these things happen almost 24/7 on IPv4 networks.

　　IPv6 addresses are 128 bits long, and the total number of addresses is 2 to the power of 128. How large is this number? To give you some comparisons: the total number of grains of sand on Earth is approximately 2 to the power of 63, while the number of IPv6 addresses is 2 to the power of 65 times that number. In other words, more than 6.5 trillion IPv6 addresses can be allocated per square meter of Earth's surface.

　　At this scale, traditional brute-force scanning methods are completely ineffective. For an attacker to find one of your servers that only runs IPv6 through random scanning is like searching for a specific grain of sand in the Milky Way. They can't simply list an address range and ping each address individually, as they would with IPv4. From this perspective, your server is indeed "hidden" in a vast ocean of addresses; attackers can't even find the door, let alone knock on it.

　　Second, "stealth" doesn't equal "immunity," and attackers' new tactics

　　However, the internet is never a place where luck matters. Attackers won't play the "guess the address" game with you; they have far smarter methods than random scanning.

　　The first method is direct location through DNS records. This is the simplest and most easily overlooked vulnerability. Many people configure AAAA records on their servers, writing the IPv6 address in the domain name resolution. An attacker only needs to perform one DNS query on your domain to obtain your IPv6 address, just as easily as obtaining your IPv4 address. Whether you enable IPv6 or not makes no difference to them; they can directly call from that address. Therefore, if you want to enjoy the stealth benefits of IPv6 but must use a domain name for external services, this advantage is essentially zero.

　　The second method is extraction from already leaked logs or sessions. If your server initiates any connections, such as accessing an external API, sending emails, or a user clicking an external link in a forum, your IPv6 address may be logged in the other party's server logs. If an attacker controls that third-party service, they can collect real IPv6 addresses in bulk. This method is much more efficient than random scanning, and many attackers on the dark web are already using this method to build target databases for IPv6 addresses.

　　The third method involves guessing based on common prefixes. Although the IPv6 address space is vast, its actual allocation follows certain patterns. Most VPS and cloud service providers publicly disclose their IPv6 address ranges. For example, a data center might allocate the 2001:db8::/32 network segment, which actually contains only 2 to the power of 64 usable host addresses. This number is still too large to scan in its entirety, but attackers can use this prefix combined with common host numbering patterns to guess the addresses. For example, many people habitually use simple suffixes like ::1, ::2, ::abcd:1234, or directly use the EUI-64 format converted from MAC addresses. These are all predictable. Furthermore, if the service provider's address allocation isn't random enough, the room for guessing becomes even larger.

　　Fourth, exploiting the IPv6 Neighbor Discovery Protocol (NDP) vulnerability. Within the same local area network, IPv6's mechanism may actually expose more information than IPv4. Neighbor requests and announcements in the NDP protocol are broadcast at the link layer. If an attacker has already entered your same network segment (such as the same Layer 2 network of the same cloud service provider), they can easily find all active IPv6 addresses within the same segment by listening to these broadcast packets. This situation is not uncommon in shared data centers and cloud environments.

　　III. From a practical attack and defense perspective, how much has the risk actually decreased?

　　Let's get down to business. For ordinary individual website owners, developers, and small and medium-sized enterprises, how many attacks can simply enabling IPv6 actually block?

　　What it effectively blocks are automated, untargeted scanning attacks that are ubiquitous across the entire internet. For example, SSH weak password brute-force attacks can scan millions of IPs a day on IPv4 networks, immediately trying passwords on any open port 22. This type of attack is virtually nonexistent on IPv6 because the attackers can't find your address. Similarly, automated scanners targeting common web vulnerabilities (such as passwordless access to phpMyAdmin or vulnerabilities in older versions of WordPress) will also have difficulty finding your IPv6 address. This level of risk is indeed significantly reduced.

　　However, it's important to note that this doesn't mean attackers can't find you. If your server engages in external interactions—for example, if your website is publicly accessible, you send emails with links, or you register on a forum and include your server address in your profile—your IPv6 address can be exposed. Once exposed, attackers will treat your IPv6 address like an IPv4 server, performing a full scan of your ports, services, and applications. At this point, all the "stealth advantage" you previously enjoyed is wiped out.

　　More importantly, certain targeted attacks are completely unaffected. If your server is targeted by a specific organization, attackers don't even need to scan it. They can obtain your IPv6 address through social engineering, domain lookups, certificate transparency logs, or even from configuration files you accidentally submitted on GitHub. In this case, simply enabling IPv6 not only provides no protection but may actually lower your guard due to over-reliance on IPv6, such as failing to configure a firewall, implement strong password policies, or implement Fail2ban protection, ultimately increasing the risk of being compromised.

　　IV. What is the real value of enabling only IPv6?

　　After so much analysis, you've probably realized that enabling only IPv6 is not a security measure, but a security strategy—more precisely, a weakened version of "security through obfuscation." It has value, but this value has strict applicable prerequisites.

　　Its true value lies in two points:

　　First, for machines without domain names, not intended for public service, and used only for personal purposes (such as web crawler servers, personal proxies, intranet penetration nodes, and backup storage), enabling only IPv6 can significantly reduce the probability of being targeted by random scans. You don't even need to configure complex firewall rules, because it's simply not on the attacker's radar.

　　Second, it can serve as a layer of "defense in depth." That is, if you already have robust firewalls, Fail2ban, key-based login, and the principle of least privilege, disabling IPv4 and enabling only IPv6 adds an extra layer of pre-screening. Even if attackers bypass all your defenses, they still need to find your address first. An extra layer is always better than none.

　　However, don't put the cart before the horse. If you haven't even implemented the most basic security configurations—for example, still using password-protected SSH logins, not configuring firewall rules, and carelessly exposing ports like 3306 or 6379 to the public internet—then enabling or disabling IPv6 won't solve the problem at all. Once your address is exposed in some way, these vulnerabilities will be exploited just like everyone else.

　　V. Practical Suggestions for Operations and Development Personnel

　　If you decide to try the "IPv6-only" route, the following suggestions are worth considering carefully:

　　First, never do this on a machine with DNS resolution. As long as your domain has an AAAA record, attackers can find your address through DNS, rendering any attempt at stealth meaningless.

　　Second, ensure that your service provider assigns truly random IPv6 addresses, not those with a predictable pattern. Some VPS providers may give you large address ranges like /64 or even /48, but the actual allocation algorithm is very simple, such as starting from ::2 and incrementing sequentially. This is entirely predictable, and while scanning is more costly, it's not impossible. If you're unsure, you can generate a random suffix manually instead of using the sequential numbering provided by your service provider.

　　Third, a firewall is still necessary. Enabling only IPv6 is not the same as running without protection. Using ip6tables to block all inbound traffic except for essential ports is the bottom line. Many people think that keeping their address hidden is all they need, but if a port is accidentally exposed and scanned, they're doomed.

　　Fourth, monitor whether your IPv6 address has been leaked. You can use online tools to check if your server has appeared in public logs, certificates, or malicious scanner databases. If your address has already appeared in web search engines like Shodan or Censys, then the so-called stealth is gone, and you should immediately implement other security measures.

　　Fifth, and most importantly: don't treat IPv6 as your only security solution. Its core function is to reduce the probability of indiscriminate scanning, not to defend against targeted attacks. If you have genuine security concerns, you should invest your efforts in system hardening, key authentication, bastion hosts, and WAFs—those proven solutions. IPv6 is an option, not a panacea.

　　So, can simply enabling IPv6 reduce the risk of scanning attacks? The answer is: yes, but with certain conditions. It can defend against the blind attacks of massive automated scripts because it makes it impossible for attackers to find your address. However, it cannot prevent two things: first, adversaries who can trace your address through DNS, logs, certificates, etc.; and second, system vulnerabilities exposed due to your over-trust.

　　Therefore, the rational approach is this: if you have a machine used purely internally, not for external service, and not for domain name resolution, turning off IPv4 and only enabling IPv6 is a very smart and low-cost strategy. But if you are providing public services or rely on domain names for external access, then you should diligently configure your firewall, harden your system, and implement robust monitoring, treating IPv6 as an additional fuse, not the sole safe haven. Network security is never a problem that can be solved by a single switch; it's a complex set of layered strategies. The IPv6 address space is just one link in this chain; it's useful, but don't over-glorify it.