Snap initially considered migrating to IPv6, but concerns about application readiness and interoperability led them to adopt dual-stack GKE nodes and GKE pods (IPv6 + Class E IPv4). This solution mitigated IP exhaustion and provided Snap with multiple years of IP address scale needed to support future growth and reduce operational overhead. In addition, this approach also aligned with Snap’s long-term strategy for migrating to IPv6.
Yet another horrible hack to avoid having to actually learn IPv6.
The first time someone calls you a horse, you punch him on the nose; the second time someone calls you a horse, you call him a jerk; but the third time someone calls you a horse, well then, perhaps it's time to go shopping for a saddle.
Years of experience with "dual stack" organizations that completely neglect the IPv6 side or do stuff like install MITM firewalls that can't handle IPv6 so the addresses are only useful internally.
Who says they don't want to learn? When your provider doesn't support IPv6-only for all your purposes (I don't know about Google but Azure and AWS doesn't do that) then you'll just exhaust RFC1918 and not work on a solution for it?
Comments
Yet another horrible hack to avoid having to actually learn IPv6.
The first time someone calls you a horse, you punch him on the nose; the second time someone calls you a horse, you call him a jerk; but the third time someone calls you a horse, well then, perhaps it's time to go shopping for a saddle.
How does using both avoid learning v6?
Years of experience with "dual stack" organizations that completely neglect the IPv6 side or do stuff like install MITM firewalls that can't handle IPv6 so the addresses are only useful internally.
Who says they don't want to learn? When your provider doesn't support IPv6-only for all your purposes (I don't know about Google but Azure and AWS doesn't do that) then you'll just exhaust RFC1918 and not work on a solution for it?