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

11–20 of 81 posts

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

#11

Post by BadBadJellyBean »

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…

I don't think that would work. The IPv6 Notation is only the human representation. Inside the package it is a 128 bit integer. IPv4 addresses can already be put there. The problem is that everyone still needs to support a package with 128 bit addresses instead of 32 bit. There is simply no space in the IPv4 package format for the 128 bit addresses. Or anything bigger than 32 bit.

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

#12

Post by dangerlibrary »

ianburrell wrote: post #9
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…

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.

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

#13

Post by dmitrygr »

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…

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.

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

#14

Post by DanAtC »

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…

There's no such thing as "backwards compatible." The IPv4 packet format is set in stone with 32 bit addresses. The "just add more bytes" meme doesn't make any sense.

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

#15

Post by ianburrell »

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.

The IPv6 address format uses hex, that is always going to be shorter than decimal. I like that it is fixed width, has zero compression, and is distinct from IPv4.

It is physically impossible for IPV4 32-bit addresses to access IPv6 with 128-bit addresses. Accessing IPv4 from IPv6 requires middleware to translate IPv6 to IPv4 and IPv4 response back to IPv4. That is NAT64.

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

#16

Post by wtallis »

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.

Making IPv4 addresses be a valid subset of IPv6 addresses would do nothing to help an IPv4 host reply to a packet from a host with a non-IPv6 address. Solving the "problem" of one-way communication without handling two-way communication is not worth anybody's time and effort.

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

#17

Post by BenjiWiebe »

DanAtC wrote: post #14
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…

There's no such thing as "backwards compatible." The IPv4 packet format is set in stone with 32 bit addresses. The "just add more bytes" meme doesn't make any sense.

But it gets brought up all the time...

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

#18

Post by RiverCrochet »

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…

IPv6 has other differences than the address length. A theme for IPv6 was to make it even easier for network equipment to process to make it faster; which aligns with "dumb fast scalable core; smart expensive edge" Internet philosophy - this is in contrast to "smart hard-to-expand core; dumb cheap edge" phone system philosophy

Compare the packets. https://www.networkacademy.io/ccna/ipv6/ipv4-vs-ipv6

> Did the authors of the standard just assume that migration and adoption would be easier than they've turned out to be?

No, but IPv4 and IPv6 can be used together (they're separate protocols) so there was no need for that.

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

#19

Post by bongodongobob »

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.

You talk about networking as if this is just about updating a regex somewhere. 32 bits is 32 bits, there's no way around that. IPv4 addresses not being valid IPv6 addresses has nothing to do with anything.

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

#20

Post by RiverCrochet »

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.

This is like saying you want to put 16 gallons of liquid in a 4-gallon bucket. It just ain't gonna fit. You need a bigger bucket. Because a lot of people are still using carts that only hold 4-gallon buckets, let them keep using the 4-gallon ones until they get tired of paying IPXO for the 4-gallon bucket rental when the 16-gallon ones are free.
Post reply on HN