If software has hardcoded ipv6 addresses, this is much harder to solve, but I don't think this is really an issue, because hardcoded ipv6 addresses appear very seldom.
But that means it has to intercept all DNS requests and doesn't work with anything it didn't intercept, which seems far from ideal.
But those don't have to be globally routable.
>it needs a big pile of ipv4 addresses to dynamically allocate whenever a new AAAA record comes through.
This wasn't really a problem until doh/dot became a thing.
But even nowadays doh and dot are provided by whom? By google and cloudflare who are tls-mitm'ing half of the internet anyway.
Moreover most ISPs intercept dns to display those "please enter your phone number to verify your identity" screens anyway.
>far from ideal.
No more imperfect than NAT. Idealism is what is killing ipv6.
All this cgnat46 setup is not in the name of end users, because they will always adapt somehow, as reels have a huge force of attraction.
It is to make sure that service providers can deploy ipv6-only _servers_ and not bother that 60 percent of their target audience will be unavailable.
The issue with the ipv6 internet is not the end users, they are paying, so the ISPs will always adapt to their needs, or the users themselves will buy new equipment in the worst case, it's the service providers who stop being profitable by going ipv6-only.
Worse is better.
Moreover, we really mostly need to make it work on http, that's enough to say "you can watch YouTube", but also deficient enough to stimulate ipv6 transition.
>given how many people here for example don't run their ISPs DNS..
Those people usually know how to deal with ipv6.
>Just seems massively complex and very resource intensive process.
No more complex than hanging in limbo for 30 years .
You mean like:
* https://en.wikipedia.org/wiki/IPv6_transition_mechanism#464X...
If an isp already has full ipv6 deployment, accommodating for ipv4 is easy.
The biggest issue is, surprisingly, not ISPs, but service providers.
> By using nat46 on ISP's routers.
I do not understand.
In Ye Olde Times a system would call gethostbyname() and this send out a DNS packet asking for the IP address. Of course DNS record returned would be an A record, which is where your first problem is: A records are fixed at 32-bits (RFC 1035 ยง 3.4.1). So your first task is to create a new record type and update every DNS server and client to support the longer addresses.
Of course the longer address has to fit into the data structures of the OS you called gethostbyname() from, but gethostbyname() is set to use particular data structures. So now you have to update all the client DNS code to support the new, longer addresses.
Further, gethostbyname() had no way to specify an address type (like if you wanted the IPv4 address(es) or the IPng one(s)):
* https://man.freebsd.org/cgi/man.cgi?query=gethostbyname&manp...
The the returned data structures only allowed for one type of address type, so you either got IPv4 or IPng. So if you wanted to be able to specify the record/address type to query, a new API had to be created.
Luckily the next step, setting up a socket() and connect()ing is less of a burden, because that API already supported different protocols:
* https://man.freebsd.org/cgi/man.cgi?query=socket&manpath=Fre...
But if you have a host that support IPng, but its upstream router does not, how does it support a packet with a longer source address a shorter destination address get through?
Do you send IPv4 packets with embedded IPng packets with-in them to translation relays perhaps? How is this any different IPv6 transition mechanisms like Teredo?