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