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