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

71–80 of 81 posts

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

#71

Post by tgma »

throw0101d wrote: post #70
tgma wrote: post #68

Earlier quoted context omitted.

> He was speaking outside his wheelhouse here He has written relatively well-known mail and DNS servers so I would not be that dismissive about him knowing a thing or two about internet RFCs. I think the GP is taking the AAAA record overly literally and nitpicking the implementation detail. The analogy in djb proposal is MX records which fall back to A record. I don't think he would mind AAAA records that fall back t…

> I don't think he would mind AAAA records that fall back to A record either, as long as the semantics are similar. He literally writes "people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software." He says, right there, that AAAA records are an "unnecessary complication". To say that he wouldn't mind them is in direct contradiction to what he wrote. Furthe…

> He literally writes "people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software." He says, right there, that AAAA records are an "unnecessary complication". To say that he wouldn't mind them is in direct contradiction to what he wrote.

Sure, you can keep attacking the implementation detail here which he may or may not have overlooked. I would rather steelman his point, as highlighted by MX analogy, is to provide AAAA as an extension to A, not an independent parallel world. DNS client that's new enough would use AAAA-only, if present, and ignore A. As implemented today, there's no way for a server to "force" the client to use AAAA and treat A as legacy.

> So you have to make sure every possible client is upgraded before you can even consider adding records with "IPv4+" addresses

Yes, my understanding of his idea is for widely deployed servers to keep using an IPv4-visible address reachable from both v6 and v4 for a long time and clients will be first updated to IPv6 outside IPv4 window.

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

#72

Post by Ekaros »

dangerlibrary wrote: post #61
ianburrell wrote: post #53

Earlier quoted context omitted.

How would IPv4 host talk through IPv6 network in your model? Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6. We'll call it NAT46, but it is deprecated because dual stack or NAT64 is better. Or could tunnel IPv4 over IPv6. We'll call this 4in6. The mistake you are making is thinking that it is hard to have dual stack. IPv4 will be running in tunnels…

> Without IPv6 network sees an unsupported IPv4 packet and throws it away. You need something to convert IPv4 to IPv6. Acknowledging my own ignorance here, assuming this sentence seemingly disregards my point, because this was a choice. The IPv6 standard chose to fix the header length at 40 bytes and operate differently from IPv4, but the standard could easily have said "We're re-using the IPv4 header format, except…

Because they also noticed that IPv4 has some design errors. So if you are anyway making something incompatible you can fix those and bring in new features.

IP packet having checksum that is also calculated on the hops remaining. Well, do you really really need that when most popular protocols TCP and UDP have also a checksum? So getting rid of it entirely is actually a smart move.

And then whole ARP, DHCP etc. Can we do something more sensible instead of that sort of thing. Different mindset, but reasonable attempt.

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

#73

Post by AnthonyMouse »

RiverCrochet wrote: post #20
dangerlibrary wrote: post #12

Earlier quoted context omitted.

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

The real trouble here is that the entities that need more addresses and the ones not supporting IPv6 aren't the same ones. In particular, a lot of large companies basically need one IPv4 address and they can NAT their whole organization behind it. Meanwhile ISPs and hosting providers need lots of IP addresses but can't switch entirely to IPv6 because their customers demand the ability to communicate with those companies that still only support IPv4.

But the government could probably fix it without even mandating anything. They should just... stop using IPv4. Does your company have to file tax forms with the IRS website? Only available via IPv6, so better get your network to support it.

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

#74

Post by api »

kstrauser wrote: post #51
api wrote: post #37

Earlier quoted context omitted.

Android still doesn't have this?

What problems does that cause for Android users? I ask because I've never deliberately set up DHCPv6 on any network and haven't missed having it. However, it's clear that others strongly do want it for presumably good reasons. What are those reasons?

Not working well on networks that use it.

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

#75

Post by ay »

tgma wrote: post #68
kstrauser wrote: post #64

Earlier quoted context omitted.

I wouldn't presume to criticize him in his areas of expertise. If he has thoughts on something involving crypto, darned if I'm going to be the one to say he's wrong. He's a sharp guy. He was speaking outside his wheelhouse here, though.

> He was speaking outside his wheelhouse here He has written relatively well-known mail and DNS servers so I would not be that dismissive about him knowing a thing or two about internet RFCs. I think the GP is taking the AAAA record overly literally and nitpicking the implementation detail. The analogy in djb proposal is MX records which fall back to A record. I don't think he would mind AAAA records that fall back t…

Falling back to IPv4 if IPv6 does not succeed is literally the day 1 behavior of IPv6 transition. Except for TCP it may take a few minutes which is clearly unacceptable. So we wrote RFC6555. It still doesn’t help in the case of PMTUD black holes, but fixes the most obvious blunders. It’s still that you need to have a common protocol between the two endpoints, there is no way around it - so he just rephrases what is essentially “transition via dual stack” strategy but with his own words.

Once again - djb is a brilliant cryptographer, an application designer and coder, and I respect him very much for his genius there.

But I maintain that his thoughts on the topic of IPv6 transition unfortunately do not share this property, and reveal that he is completely ignorant of a lot of practical factors that are at play in that context.

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

#76

Post by ay »

tgma wrote: post #71
throw0101d wrote: post #70

Earlier quoted context omitted.

> I don't think he would mind AAAA records that fall back to A record either, as long as the semantics are similar. He literally writes "people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software." He says, right there, that AAAA records are an "unnecessary complication". To say that he wouldn't mind them is in direct contradiction to what he wrote. Furthe…

> He literally writes "people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software." He says, right there, that AAAA records are an "unnecessary complication". To say that he wouldn't mind them is in direct contradiction to what he wrote. Sure, you can keep attacking the implementation detail here which he may or may not have overlooked. I would rather stee…

His idea, if I understand it right, is to do two transitions instead of one: 1) first, add 12 bytes to each address 2) then build out the IPv6 on this free space.

The problem is that (1) can not happen everywhere at once. So your “128bit IPv4” stack still needs a way to talk to “32 bit IPv4” stack, so you need to maintain somewhere a flag which one do you use.

So the problem is exactly the same as with the transition - you need dual stack everywhere, and a means to select which one to use.

I think the simplest analogy of this that makes the complexities more obvious to understand:

Imagine you have a network based on copper. (Twisted pair). Please upgrade the entire network to the optical fiber while maintaining the transparent connectivity between all the hosts at all times.

Edit to add:

bad analogy. Copper or fiber are sufficiently non-leaky to make the task relatively simple. Maybe a better one could be to migrate the hosts from IP to IPX. (Which is kinda similar to IPv6 sufficiently that it renders the analogy moot :)

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

#77

Post by Hikikomori »

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…

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?

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

#78

Post by Hikikomori »

solatic wrote: post #30

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

There's an RFC to use it in the Internet, unlikely to be ratified though.

Usually because your provider does not fully support IPv6 yet, which is the case at least with Azure and AWS, likely Google as well.

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

#79

Post by throw0101d »

tgma wrote: post #71
throw0101d wrote: post #70

Earlier quoted context omitted.

> I don't think he would mind AAAA records that fall back to A record either, as long as the semantics are similar. He literally writes "people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software." He says, right there, that AAAA records are an "unnecessary complication". To say that he wouldn't mind them is in direct contradiction to what he wrote. Furthe…

> He literally writes "people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software." He says, right there, that AAAA records are an "unnecessary complication". To say that he wouldn't mind them is in direct contradiction to what he wrote. Sure, you can keep attacking the implementation detail here which he may or may not have overlooked. I would rather stee…

> DNS client that's new enough would use AAAA-only, if present, and ignore A. As implemented today, there's no way for a server to "force" the client to use AAAA and treat A as legacy.

This is exactly how Happy Eyeballs works: request AAAA and A, and use AAAA if it returns.

Trying to force things one way or another is a recipe for a bad user experience.

Post reply on HN