4 ms·
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.
by tgma 2y ago
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.
- ay 2y agoQuote 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”.
- throw0101d 2y agoAlso 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 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.
- ay 2y agoYeah. “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 :-)
- kstrauser 2y agoI 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.
- tgma 2y ago> 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.
- kstrauser 2y agoThe main problem there is that what wished for was utterly impossible. RFC 1035 (https://www.ietf.org/rfc/rfc1035.txt 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.
- throw0101d 2y ago> 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).
- kstrauser 2y agoIt's almost always cited as exactly that: a reason why people are avoiding IPv6, as though it's proof that IPv6 is too hard to use, and that we could all be on it already if only we'd taken his advice. 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.