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.
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 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.
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).
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.
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 :)
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.
The intent with Happy Eyeballs was to focus on user experience: give IPv6 a slight initial advantage to hopefully only make only an IPv6 connection for the dual stack and not waste the network resources and CGNs bindings.
But at the same time, a short time after the start of the IPv6 connection, the IPv4 connection would also be initiated. Whichever connection wins, tilts the balance towards that address family for the next attempts.
This way the users on a broken or very slow IPv6 with fast IPv4 can still have a good experience, Internet Holy Wars notwithstanding.
Source: I am one of the two coauthors of the RFC6555.
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.
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.
Comments
Also from the document:
"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.
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 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.
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).
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.
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.
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 :)
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.
Actually it is a little bit more subtle.
The intent with Happy Eyeballs was to focus on user experience: give IPv6 a slight initial advantage to hopefully only make only an IPv6 connection for the dual stack and not waste the network resources and CGNs bindings.
But at the same time, a short time after the start of the IPv6 connection, the IPv4 connection would also be initiated. Whichever connection wins, tilts the balance towards that address family for the next attempts.
This way the users on a broken or very slow IPv6 with fast IPv4 can still have a good experience, Internet Holy Wars notwithstanding.
Source: I am one of the two coauthors of the RFC6555.
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.
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.