If you are a user sure. There are ways to bridge IPv6 to IPv4 (A router someplace translates for you, I suppose NAT but I'm not an expert on how this works), while going the reverse is harder because there is no way to bridge IPv4 to IPv6. There are a lot of people running IPv6 only who don't even know it. (most cell phones for example)
Only server administrators need to care, and there they have a problem. If you run real IPv4 only: then IPv6 only users can talk to your server no problem and won't even realize anything is happening. If you run IPv6 only there are a lot of IPv4 only users who cannot connect to you. Thus if you run a server it is critical to have a real IPv4 address.
Did you notice the "real" qualifier to IPv4 in that last paragraph? many (most?) IPv4 only users are behind a NAT system such that they cannot run a server anyway. If you are running a IPv4 Server you need an address of the type that RIPE just ran out of. If you are a user you can use a fake IPv4 address and keep on working.
If you are a server administrator you should ensure that all your servers have IPv6 addresses. You should then collect statistics on use. There may be a date in the future where you can suggest to your management that you can cut off [small number]% of your users by going IPv6 only and selling your existing IPv4 address to the highest bidder for $$$. That is a business decision, but once it starts happening it will make headlines, but I wouldn't want to be first. (if you wait too long enough others will have gone IPv6 only that there isn't a real customer cost to being IPv6 only and then the market for IPv4 will disappear - and interesting value maximization problem if you want to play that game)
NAT is an acronym for "Network Address Translation" so that's the right term to use.
NAT approaches to bridge IPv6 and IPv4 exist and work as well as IPv4-to-IPv4 NATs, that is to say pretty poorly: but we've long since adjusted the architecture of Internet-enabled software to cope with the flaws, so practically speaking they work just fine.
We've been down a road for a while now of funnelling all of the Internet's services into something-over-HTTP, so running a server might need a public IPv4 address, but as the supplies already assigned to LIRs by the RIPE NCC (and other RIRs) start to dwindle I expect we'll see more services offered whereby you can share an HTTP front end with a bunch of other people, proxied to an IPv6 (or private space) server you run.
I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones. While you can easily map the entire IPv4 address space into an IPv6 subnet of your choosing this is obviously not possible the other way around. Address mapping would have to be highly dynamic to work at all and there would be no real guarantee addresses stay the same that way. Additionally in order to make this work more or less transparently DNS responses have to be modified breaking in presence of DNSSEC validation (the same as DNS64 in reverse). One could probably avoid this by using something like reverse DS-Lite which is more or less NAT with tunneling combined.
A more common approach to reach IPv6 networks from IPv4 ones is tunneling the traffic on top of your existing IPv4 network. This way you become fully addressable and able to reach both networks almost like you would have been able to with a dual stack setup except that the tunnel reduces your MTU because of the tunneling and that you need an remote endpoint with support for both networks that routes packets to your tunnel accordingly.
Using IPv6 only makes it impossible to reach you from an IPv4 only node while still making it easy to reach other IPv4 host from your side using only NAT techniques. Using IPv4 only its unfeasible to reach arbitrary IPv6 hosts using NAT only and a tunnel setup is more or less required to make it work properly.
> I don't think that the use of NAT at that level is really feasible to bridge IPv4 networks to IPv6 ones.
Not only has CGNAT existed doing this at scale for many years in SE Asia, it commonly happens on cell networks in the US now even, so yes, it’s feasible.
One more reason to reconsider the design of DNSSEC and take it back to the drawing board, since it has virtually no meaningful deployment today anyways, and is already badly flawed.
There's nothing wrong with the design of DNSSEC. It's just doing its job, making sure that the addresses in the DNS replies match the RRs configured by the domain owner and preventing MitM attacks against the DNS system. The issue is DNS64, which for all intents and purposes is a form of MitM attack: If you can run a transparent DNS64 service you can redirect traffic however you want. You're not limited to faking "equivalent" AAAA records which send traffic to the correct IPv4 server. This is incompatible not only with DNSSEC in particular but with any attempt to ensure the end-to-end integrity of domain resolution. Anyway, we already have a solution to the problem of IPv6-only networks connecting to IPv4 servers which doesn't depend on manipulating DNS entries: DS-Lite.
The job it does has very little operational value, and it breaks things we care about. In just a few months of deployment, DoH has done more to protect DNS queries than DNSSEC has in almost 25 years of work. Any time you look at something that DNSSEC makes harder, your first thought should be, "is the real problem here that we're trying to do tree-PKI DNSSEC in the first place"? I'd content that's always the case.
DoH and DNSSEC are orthogonal systems. DoH protects the connection from the client to the resolver from eavesdropping or tampering, but doesn't do anything to ensure the integrity of the records reported to the resolver (which still uses regular DNS) and doesn't prevent the resolver itself from tampering with the data. The aim of DNSSEC is to provide for the end-to-end integrity of the RRs so that a client can be sure that the reported data matches the data entered by owner of the domain. This is essential for protocols such as DANE. The introduction of DoH does not eliminate the need for DNSSEC and the two protocols can be used together.
At this point, I'd say DANE is more essential for DNSSEC than DNSSEC is essential for DANE. But both are solutions casting about desperately for a problem to solve; in DNSSEC's case, for more than 20 years, through repeated false starts in design.
The comparison with DoH is imperfect, certainly, but still probative. DoH does something, today; it protects queries to sites all around the Internet, and doesn't depend on a boil-the-ocean deployment that must occur simultaneously in two directions (from the service operators who must sign their zones and from the end systems which must upgrade and enable DNSSEC). DoH is a relatively young protocol and will, within the next year or two, be almost completely mainstream, a feature of most of the deployed base of browsers. DNSSEC will still be languishing, because we aren't humane enough to drag it out to the yard, rifle in hand, to put it out of its misery.
