Earlier quoted context omitted.
> and DHCPv6 So long as you don't have to care about Android, maybe.
Android still doesn't have this?
Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
51–60 of 81 posts
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#52djb 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.
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#53Earlier quoted context omitted.
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.
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…
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 for a long time, just like IPv6 run in tunnels in early days. There are enough IPv4 addresses for servers for a long time. Eventually, IPv6 will be the norm and nobody will care about IPv4 except for running old hardware and software.
Upgrading just networking software is impossible since client software needs to be upgraded to support longer addresses. In particular, they need to support the generic interfaces that work with multiple protocols.
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#54It 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…
You mean RFC 4291's ::ffff:0:0/96?
* https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5
* https://www.iana.org/assignments/iana-ipv6-special-registry/...
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#55Earlier 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.
Huh? It is not a rationale for avoiding IPv6. Quite the contrary. It is a critique on how IPv6 was designed without being interoperable with IPv4 address space. It is very clear that he was right given there are 22 more years of evidence of IPv4 still being very much with us, and foreseeable future.
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#56Earlier quoted context omitted.
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.
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…
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 only has addresses that are 128 bits. How would an IPv4-only client, which only knows about 32-bit addresses, deal with a 128-bit address? The only address that the IPv6-only server has is 128 bits: how are you supposed to fit those bits in the 32-bit data structures of the IPv4-only client.
If a the server is IPv6-only, then its DNS records have to be 128-bits as well: how does that work with DNS A records, which are hard-coded to 32-bits? That's why AAAA records were invented: to with 128 bits. Now you're talking about update DNS server for new record types, resolver code to request A and AAAA records. Of course after you do a lookup to get the IP, you have generally want to connect, so you call socket(2) and then connect(7), so the latter has to be re-coded to understand 128-bit addresses.
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#57Earlier 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…
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#58Earlier quoted context omitted.
Huh? It is not a rationale for avoiding IPv6. Quite the contrary. It is a critique on how IPv6 was designed without being interoperable with IPv4 address space. It is very clear that he was right given there are 22 more years of evidence of IPv4 still being very much with us, and foreseeable future.
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”.
> 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 just broken your DNS completely: IPv4 no longer works for some people, and neither does IPv4+.
So you have to wait until all client software understands extended-A records—but what's the motivation for enabling new client software if no one is enabling server-side records because there's no client software. Chicken-egg.
Which is one argument against IPv6: why enable client-side when there's no content, and why bother server-side if there are no client requests? Chicken-egg.
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#59Earlier 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…
> 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…
Re: Leveraging Class E address space to mitigate IPv4 exhaustion issues in GKE
#60Earlier 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.
Huh? It is not a rationale for avoiding IPv6. Quite the contrary. It is a critique on how IPv6 was designed without being interoperable with IPv4 address space. It is very clear that he was right given there are 22 more years of evidence of IPv4 still being very much with us, and foreseeable future.
It also completely misses the real reason we're not further along: people turned out to be willing to tolerate NAT's breakage. If we actually had to have a public IP per device, we'd have switched already. Instead, ISPs said hey, what if we put your entire house/apartment/office/city behind the same IP? And no one got guillotined or anything, so they did. DJB didn't mention that at all.