Recently to help customers troubleshoot a bizarre network problems, the other party swore that the server was DDoS penetration, I went up to take a look at the traffic curve on the music - it is clear that the IPv6 client request was the old CDN nodes as anomalous traffic to the wrong kill. The customer asked me with wide eyes: “Where does anyone use IPv6 now?” I directly cut the mobile hotspot to the 5G network and passed it over: “Try it yourself, the proportion of IPv6 addresses assigned by 5G base stations is almost 90% now.”
These days the network environment is becoming much faster than imagined. Last year, the global IPv6 penetration rate officially exceeded 40%, and the proportion of IPv6 traffic in the mobile networks of the three major domestic carriers even exceeded 50%. However, the configuration of the high-defense CDN of many enterprises is still stuck in the primary stage of the dual-stack architecture, and they do not even realize that IPv6 is not an option but a mandatory option. The first time I saw it, it was a “mandatory option”.
The most damaging is the address translation security issue. Traditional NAT44 program in the IPv6 environment is like using a bamboo fence to prevent tanks - last year, a well-known e-commerce company's IPv6 conversion vulnerability led to more than 7,000 user sessions hijacked, the root cause is the CDN vendor's conversion rules misconfiguration.
Tests have found that most traditional high-defense CDNs have three major fatal injuries in their IPv6 support: discarding security header information during protocol conversion, lack of IPv6-specific traffic cleaning rules, and mandatory downgrading to IPv4 when going back to the source. a well-known vendor claiming to support IPv6 has a node that directly clears the Flow Label field of IPv6 for transmission, which is a tawdry operation that directly undermines the continuity of the flow identity. This kind of operation directly destroys the continuity of flow labeling.
Don't believe the vendor's propaganda of “perfect compatibility with IPv6”. I tested eight mainstream CDN services last year, and only three of them really realized full-link IPv6 support. Among them, CDN5's performance is the most surprising, not only supports IPv6 native Anycast, but also can configure IPv6 DDoS protection thresholds individually in the console. In particular, their intelligent routing protocol allows precise scheduling based on the geographic location of IPv6 address segments.
08Host's solution is a bit more tricky - protocol conversion through a two-tier proxy. Although it can solve the compatibility problem, the additional 3 ms delay is a disaster for games and financial scenarios. On the contrary, CDN07 has developed a very interesting “IPv6 fingerprint library”, which can identify more than 500 IPv6-specific attack patterns, such as Neighborhood Discovery Protocol (NDP) flooding attacks, a classic routine.
Configuring a high defense CDN to support IPv6 is definitely not as simple as turning on the switch. First of all, you have to check whether the SSL certificate supports IPv6. Last year, we encountered the pitfall of Let's Encrypt certificate failing to handshake on a pure IPv6 link. It is recommended to use this command to test the integrity of the certificate chain:
The most critical is the address translation security policy. Now the mainstream program is a combination of NAT64+DNS64, but many O&Ms directly copy the ACL rules of IPv4, and as a result, all the extended header information of IPv6 is filtered out. The correct approach should be to configure security groups like this:
Traffic cleaning strategies are even more important to optimize individually. the /48 address block of IPv6 is equivalent to the entire IPv4 address space. traditional defense rules based on the number of IPs are directly ineffective. It is recommended that a dynamic reputation scoring mechanism be used. such as the solution implemented by CDN5:
The design of back-to-source architecture is even worse. Some vendors directly engage in IPv6 to IPv4 conversion to save time, this program is bound to have problems when encountering the PMTU discovery protocol. A safer approach is to let the edge node dual-stack back to the source, such as CDN07 on the implementation of intelligent protocol selection: when the quality of the IPv6 back to the source link is lower than the threshold automatically switch to IPv4, while maintaining the consistency of the session.
Recently, when we helped a video website to do migration, we also found a hidden trap - the MTU problem of IPv6. Since IPv6 prohibits sharding, the tcp-mss parameter must be explicitly configured when the CDN node uses 1480 bytes MTU and the user side uses 1500 bytes:
The monitoring aspect also has to be fully upgraded. The traditional IPv4 monitoring dashboards do not show the key indicators of IPv6 traffic, so we have developed a three-dimensional map of IPv6 traffic with geographic information, which can visualize the correlation of attacks on different address segments. This tool was used to identify anomalous traffic from the 2001:db8::/32 address segment, which was eventually traced back to a country's IPv6 network scanning program.
To be honest, the IPv6 support of many security vendors is now dealing with inspections. The last time I saw a product's vulnerability protection rules, IPv6-related rules are only one-tenth of IPv4, the effect of this kind of protection might as well be turned off. If you really want to do a good job of protection, it is recommended that you refer to the IPv6 security guidelines published by NIST, or at least take into account the characteristics of address privacy extension and temporary address rotation.
After more than half a year of battle test, we finally chose CDN5 as the main service provider and 08Host for disaster recovery and backup. We especially appreciate CDN5's real-time threat map function, which can show the correlation between IPv4 and IPv6 attack chains at the same time. Once when defending against an 800Gbps IPv6 flood attack, their cleaning node was able to identify the fingerprint of the hijacked IoT device and directly cut off the control link of the C2 server.
Recently, I just helped an exchange to complete the full-stack IPv6 transformation, and the most profound experience is that IPv6 is not a simple change of address format, but an upgrade of the whole security system. Now the latency of their trading system has been reduced by 17% because IPv6 avoids the overhead of NAT conversion. What's more, they have never encountered the ARP spoofing problem of the IPv4 era, after all, the IPv6 neighbor discovery protocol has an encrypted authentication mechanism.
If I had to recommend a migration plan now, I'd say: hurry up and upgrade your dual-stack architecture to a pure IPv6-first architecture, and stop holding on to IPv4. The latest research data shows that the cost of attacking a pure IPv6 link is 40% higher than IPv4 because the scanning efficiency drops dramatically due to the large address space. This is simply a natural barrier for the defense.
One last piece of cold knowledge: Windows systems prioritize IPv6 by default, and when your CDN doesn't support IPv6, users actually experience a delay in protocol fallback. This detail is enough to explain why some websites with the same configuration load faster and some slower - the secret is in the millisecond difference in address resolution.
