from Hacker News

Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE

by l1n on 10/23/24, 4:40 PM with 77 comments

  • by RadiozRadioz on 10/23/24, 4:52 PM

    > However not all enterprises or applications are ready for IPv6 yet.

    I don't think this statement will ever be false in my lifetime.

  • by dangerlibrary on 10/23/24, 5:04 PM

    It never made sense to me why the authors of the IPv6 standard chose to use an entirely different address format, instead of extending address space in a backwards-compatible way. Why not just append/prepend the 12 additional bytes onto existing IPv4 addresses, and write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

    I'm not an RFC author, but something like "All existing IPv4 addresses will be reachable under the 0.0.0.0.0.0.0.0.0.0.0.0 prefix in the IPv6 Standard" seems like it would've made migration relatively trivial.

    The draft standard is 26 years old. The official standard is 7 years old, and we are still reading articles about how "not all enterprises or applications are ready for IPv6 yet."

    This question is coming from a place of genuine confusion and curiosity - I really don't get it. Did the authors of the standard just assume that migration and adoption would be easier than they've turned out to be? Was it a fairness issue where somehow this would have granted dominion over huge swaths of the new address space to existing players?

  • by ddtaylor on 10/23/24, 4:51 PM

    Anything but IPv6 it would seem.

  • by jandrese on 10/23/24, 4:53 PM

    > 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.

  • by solatic on 10/23/24, 6:50 PM

    Incredibly unsafe. If Class E is reserved "for future use", maybe that could include public use. The first rule of hardening production reliability is, make sure it doesn't just work, but that it will continue to work. Tomorrow, some customer of yours gets assigned addresses from Class E. Have fun untangling that.

    Why not stop this bullshit and just transition to IPv6??

  • by hypeatei on 10/23/24, 4:56 PM

    Interesting read, but it seems like a waste of time to keep finding little tricks and band aids with IPv4 when v6 exists.

    > However not all enterprises or applications are ready for IPv6 yet

    Ah yeah, there it is. Please, just fucking prioritize upgrading to IPv6 and be done with it. Frustrating.

    Cloud providers need to hurry up as well, Azure still doesn't fully support v6 on their app services (web servers) either. It's in public preview but has been a roadmap item for longer. It also comes with certain caveats like what tiers can use it.

  • by sulandor on 10/23/24, 7:57 PM

    amazon (among others) is doing this for some time

    rfc's have been written and forgotten, please calm down

  • by ffhcx on 11/5/24, 7:35 PM

    y

  • by tgma on 10/23/24, 5:59 PM

    djb on IPv6 incompatibility being a bad design choice: https://cr.yp.to/djbdns/ipv6mess.html

  • by ay on 10/23/24, 8:30 PM

    “ As mentioned in Google VPC network valid IPv4 ranges, Class E addresses (240.0.0.0/4) are reserved for future use, as noted in RFC 5735 and RFC 1112 — however, that doesn’t mean you can’t use them today in certain circumstances.”

    Wow. reserved means “kept aside”. Once someone starts using them, they stop being kept aside.

    This means that de-facto they are private addresses now. I suppose it’s a pragmatic choice.

    But, wow, so much for having interactions in relevant standards bodies, multistakeholder engagements, etc. Why bother. Classy. /s