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

61–70 of 81 posts

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

#61

Post by dangerlibrary »

ianburrell wrote: post #53
dangerlibrary wrote: post #40

Earlier quoted context omitted.

Just to address the implication (prevalent in many of the sibling comments as well) that I and everyone else who talks about this are idiots incapable of grasping that 128 is larger than 32: If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, router…

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 now addresses are variable-length up to 128 bits."

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

#62

Post by ay »

throw0101d wrote: post #58
ay wrote: post #55

Earlier quoted context omitted.

Quote from the doc: “ Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place.” - this text is pretty much the definition of “IPv6 transition”.

Also from the document: > Unfortunately, instead of simply allowing 16-byte A records, people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software. "Simply". Yeah. Until some non-upgraded client gets an 'extended-A' record response that's the "wrong" size (according itself) and drops the packet (which is the sane thing to do security-wise) and then you've j…

Yeah. “Why don’t you just…” :-)

djb has a lot of brilliant ideas and excellent implementations of them. But this is neither.

On the flip side this article could serve as a great example of a Nobel disease :-)

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

#63

Post by kstrauser »

dangerlibrary wrote: post #59
throw0101d wrote: post #56

Earlier quoted context omitted.

> If 32 bit IPv4 addresses are valid IPv6 addresses without fiddly NAT64/DNS64 shenanigans, then (it seems to me) IPv4-only clients could blithely continue to interact with the IPv4-accessible internet via IPv6-only servers, routers, etc. indefinitely If you have an IPv4-only client and an IPv6-only server (i.e., has no IPv4 address), you need a IPv4-IPv6 relay. Because if the IPv6-only server is truly IPv6-only, it…

You are correct, given the assumption that an IPv6-capable server or host has no IPv4 address. I attempted to acknowledge that such a server would be unreachable from an IPv4 client.

Thing is, all interesting Internet services require 2-way communication. Suppose you had an IPv6 client trying to talk to an IPv4 server. With that scheme, the initial packet could get routed to the server by dropping the first 96 bits of the address and treating the rest like an IPv4 address. But where do you put those other 96 bits so that the server can send its reply packet back to the originating client?

You can use NAT64 which does exactly that. If you're doing that anyway, there's not much advantage to adding all the complexity directly into the protocol.

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

#64

Post by kstrauser »

ay wrote: post #62
throw0101d wrote: post #58

Earlier quoted context omitted.

Also from the document: > Unfortunately, instead of simply allowing 16-byte A records, people introduced new ``AAAA records'' into the DNS protocol, creating several unnecessary complications in DNS software. "Simply". Yeah. Until some non-upgraded client gets an 'extended-A' record response that's the "wrong" size (according itself) and drops the packet (which is the sane thing to do security-wise) and then you've j…

Yeah. “Why don’t you just…” :-) djb has a lot of brilliant ideas and excellent implementations of them. But this is neither. On the flip side this article could serve as a great example of a Nobel disease :-)

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.

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

#65

Post by RiverCrochet »

wmf wrote: post #48
dvh wrote: post #43

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Second-system_effect

IPv6 definitely suffers from some amount of second-system effect but (I cannot stress this enough) that's not the cause of its failure. A minimal IPv4+ upgrade would still have failed for the same reasons .

IPv6 is actually working right now for many so I wouldn't call it a failure. Use of IPv6 has been increasing over time and who really cares how fast that is happening? Some ISPs, nodes or networks may never use it - but that's OK; really as long as major cell phone networks are using it, it's not going away.

Windows XP is another example of something that lingered far longer than it should have. It's not a failure just because everyone didn't immediately start using it.

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

#66

Post by RiverCrochet »

kstrauser wrote: post #42
tgma wrote: post #22

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

His points were wrong 22 years ago, and they continue to be wrong today. It's a poor document to cite as a rationale for avoiding IPv6.

I found this humorous, the article literally says this:

"Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place."

As though this is any easier than just introducing IPv6 as a new, parallel protocol that does not have to interoperate (because IPv4 still works). I'm sure he can update his software and systems but what about the thousands of other programs and billions of other machines.

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

#67

Post by tgma »

RiverCrochet wrote: post #66
kstrauser wrote: post #42

Earlier quoted context omitted.

His points were wrong 22 years ago, and they continue to be wrong today. It's a poor document to cite as a rationale for avoiding IPv6.

I found this humorous, the article literally says this: "Answer: We go through every place that 4-byte IPv4 addresses appear, and allow 16-byte IPv6 addresses in the same place." As though this is any easier than just introducing IPv6 as a new, parallel protocol that does not have to interoperate (because IPv4 still works). I'm sure he can update his software and systems but what about the thousands of other programs…

> I'm sure he can update his software and systems but what about the thousands of other programs and billions of other machines.

Well, empirically, we can see what we have now is that the software on billions of machines have been updated, but the transition has not completed. You have to eventually get there one way or another for the full transition, regardless of your transition methodology.

So, yes it may very well have been "easier" (as in shorter timeline) in the long term to accomplish the full transition under djb proposal.

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

#68

Post by tgma »

kstrauser wrote: post #64
ay wrote: post #62

Earlier quoted context omitted.

Yeah. “Why don’t you just…” :-) djb has a lot of brilliant ideas and excellent implementations of them. But this is neither. On the flip side this article could serve as a great example of a Nobel disease :-)

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 to A record either, as long as the semantics are similar.

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

#69

Post by kstrauser »

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…

The main problem there is that what wished for was utterly impossible. RFC 1035 (https://www.ietf.org/rfc/rfc1035.txt) section 3.4.1. "A RDATA format" defines an A record's data field as "A 32 bit Internet address." His change would require redefining that in a backward-compatible way, then incrementally upgrading every DNS server and client on the Internet to support both types of data in the same RDATA.

That sounds a whole awful lot like the exact problem he hoped it would solve.

And having written a nameserver and knowing what that ecosystem looks like, he knew that. And being famously security conscious (and competent), he knew what it would look like to get all the OS vendors to parse a 32 bit A record RDATA field as IPv4, and a 128 bit one as IPv6, and any other value as invalid, 100% of the time so that you didn't accidentally create a vulnerability by truncating addresses or such. It would've been chaos.

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

#70

Post by throw0101d »

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…

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

Further down after that he writes that the "client software, intermediate computers, and server software have all been upgraded to handle the client's extended address."

But what happens where there's software that is not upgraded? IMHO, if it's sane, it would reject the packet as malformed as security precaution. Congratulations, you've now broken DNS on the ('legacy') client. So you have to make sure every possible client is upgraded before you can even consider adding records with "IPv4+" addresses.

Or you could simply have two record types (e.g., A and AAAA) and legacy clients use one and updated clients the other, and you don't have to worry about breaking what already is working (plain-IPv4).

Post reply on HN