Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cloud.google.com

Post reply on HN
Print view View original

21–30 of 81 posts

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

#21

Post by jandrese »

dangerlibrary wrote: post #8

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 addresse…

> write the standard such that all valid IPv4 addresses are also valid IPv6 addresses?

This already exists. 2020:abcd:abcd::192.168.0.1 is a valid IPv6 address. Most applications will parse it just fine.

NAT64 has been around for ages and mostly works, but is pretty ugly so few people want to actually deploy it.

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

#23

Post by wmf »

dangerlibrary wrote: post #8

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 addresse…

Extending IPv4 seems like it would work until you get into the details. You discover that any new protocol is going to have similar adoption problems. https://archive.ph/eHvKF https://news.ycombinator.com/item?id=10854570

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

#24

Post by yjftsjthsd-h »

dangerlibrary wrote: post #12
ianburrell wrote: post #9

Earlier quoted context omitted.

Because writing the addresses is not the important part. You can write IPv6 addresses as dotted decimal. The length is the problem, IPv6 format is more compact. Addresses are not the hard part in upgrading. The embedding doesn't help with compatibility. IPv4 still can't access IPv6. IPv6 can't access IPv4. It actually breaks NAT64, which depends on special prefix. Also, extending IPv4 address space has the problem th…

"The length is the problem, IPv6 format is more compact." "IPv4 still can't access IPv6. IPv6 can't access IPv4." I guess my point is that these statements represent choices made by humans. Leaving the decimal representation aside, I don't get why they made these choices. If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

To some degree, no it's not a choice; you can't fit a 128-bit address in 32 bits. However, to the degree that it is possible, that exists; NAT64 does make every valid IPv4 address a valid IPv6 address.

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

#25

Post by yjftsjthsd-h »

jandrese wrote: post #6

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

How does using both avoid learning v6?

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

#27

Post by AnthonyMouse »

dangerlibrary wrote: post #12
ianburrell wrote: post #9

Earlier quoted context omitted.

Because writing the addresses is not the important part. You can write IPv6 addresses as dotted decimal. The length is the problem, IPv6 format is more compact. Addresses are not the hard part in upgrading. The embedding doesn't help with compatibility. IPv4 still can't access IPv6. IPv6 can't access IPv4. It actually breaks NAT64, which depends on special prefix. Also, extending IPv4 address space has the problem th…

"The length is the problem, IPv6 format is more compact." "IPv4 still can't access IPv6. IPv6 can't access IPv4." I guess my point is that these statements represent choices made by humans. Leaving the decimal representation aside, I don't get why they made these choices. If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

> If every IPv4 address were a valid IPv6 address, then these statements wouldn't be true.

This is already the case. The format for representing IPv4 addresses in IPv6 is to encode the first 96 bits of the address as ::ffff and the last 32 bits as the IPv4 address, e.g. 192.0.2.128 as ::ffff:192.0.2.128. You can also encode the last 32 bits as hex if you want (::ffff:c000:0280 is the same address) but then it's less obvious what the IPv4 address is.

The problem is that every IPv6 address is not a valid IPv4 address, because the IPv4 address space is smaller so there is no way to do that without some kind of NAT or similar, which also exists but sucks in various ways.

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

#28

Post by ploxiln »

dangerlibrary wrote: post #8

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 addresse…

They actually did that (see sibling replies), and it actually delayed adoption of ipv6 by a few more years, because of things like:

  1. some OSes can listen on ipv6-mapped-ipv4 automatically when some application listens on ipv4
  2. app is updated to listed on both ipv4 and ipv6
  3. at various companies, the updated app fails to start, because it listened on ipv4, which automatically listened on ipv6, and then it tried to listen on ipv6 and failed because the port was already in use
  4. The problem is weird and confusing, and the easiest fix is to just disable ipv6 everywhere: in the app, in the OS, everywhere. Then the app works again.
  5. The config changes remain untouched for many years (subtle config issue, don't touch!)
I think ipv6 would be more widespread if various auto-adaptation mechanisms were never introduced: 6to4, teredo, etc. I personally experienced this in my teens, one day my browser took 30 seconds to start loading any web page, and just disabling ipv6 everywhere fixed it, and for the next couple years browsers disabled ipv6 by default (whereas they previously were agnostic), and macOS also did a similar thing where it reduced ipv6 enablement by default for a few years, also domains like google.com and facebook.com removed AAAA records they previously had for a few years. They just can't tolerate 1% to 3% of users breaking due to ipv6 mis-config. Adoption would have been much smoother and faster overall, without these significant contributors to automatic-possibly-broken ipv6.

(Yes IPv6 works fine now, with happy-eyeballs, and DHCPv6, and pretty much only real-native ipv6 used anywhere)

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

#29

Post by jandrese »

yjftsjthsd-h wrote: post #25
jandrese wrote: post #6

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

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.

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

#30

Post by solatic »

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

Post reply on HN