It's an article of faith that IPv4 hosts should mostly have valid reverse DNS and that good sysadmins (and people in general) should set this up for their hosts. While support for this is not exactly universal, it is reasonably common and many places have it. However, in light of my recent experiences with IPv6 I've come to believe that a significant number of IPv6 hosts will probably not have reverse DNS.

When I was thinking that IPv6 hosts would acquire addresses through DHCP(6), reverse DNS seemed as feasible for them as it does for IPv4 hosts that also use DHCP (although I had questions about what the names would be). It'd be somewhat more annoying to set up (because IPv6 PTR records are longer), but doable and even routine. But Android means that that's not really on, since Android (including Chromebooks) does not support DHCP6 at all; instead, hosts will acquire and use IPv6 SLAAC addresses, which means at least a couple of addresses per host, spread randomly and relatively unpredictably over your IPv6 PTR space. Worse, an increasing number of IPv6 hosts are likely to use temporary addresses for privacy reasons.

Given SLAAC and temporary addresses, it seems that the only particularly feasible reverse DNS for such IPv6 /64s is completely bland generic reverse DNS. At that point, why bother? The reverse DNS is serving almost no meaningful purpose apart from, well, having reverse DNS, and presumably you need special DNS servers that don't try to materialize all of those records in memory, just fill them in from a template when queried. (This has implications for your secondary DNS servers.)

(It's possible that some form of dynamic DNS could sort of fix this, but dynamic DNS is its own additional layer of complexity and I don't know if IPv6 hosts politely tell you what SLAAC IPv6 addresses they have decided to use so that you can add them to DNS on the fly.)

At this point, if someone at my ISP offered to delegate the necessary reverse DNS zone for my IPv6 /64 to me so that I could have proper reverse DNS for it, I would just laugh. Setting up and maintaining even entirely generic IPv6 reverse DNS would be too much of a hassle. I might someday have reverse DNS for a few static IPv6 addresses for things like my home Linux machine, but not for all of those SLAAC and temporary addresses from things on my home wireless network. And I doubt I'm going to be alone here.

(Possibly this is already obvious to anyone who has ever done much with IPv6. As you can tell, I'm just getting my feet wet here, mostly by throwing myself in the water when random new pieces of hardware show up instead of any systematic process of exploration and education.)

PS: In a real IPv6 deployment I'd still do reverse DNS for static IPv6 addresses. I think that this is useful internally, for the obvious reason that meaningful names are easier to recognize than addresses. If you're looking at internal logs, 'connection from <host X>' is obviously easier to follow and use than 'connection from <IPv6 address>', so it's worth some effort to get it.

Sidebar: Why generic reverse DNS is not very useful internally

The purpose of names is to give short, recognizable labels to things. Dynamically generated reverse DNS can sometimes do this, but generally only when it's relatively sparse and you can have names like 'dhcp0-NNN.red.sandbox' or 'unregistered-NNN.red.sandbox'. When you have to densely populate the reverse DNS namespace and generate names like '76.103.17.172.red.sandbox', the names are not really helping you very much.

All forms of SLAAC addresses are going to be relatively randomly distributed over your IPv6 /64; that's why you have to give SLAAC an entire /64. To make sure every randomly chosen, randomly distributed address has reverse DNS, you must densely populate the reverse DNS namespace, which means that you are not going to wind up with meaningful short labels. The label will just tell you what IPv6 address it has.

You can use generic reverse DNS for IPv6 addresses to tell you what network the IPv6 address is on. In this case the meaningful content of the name is actually the '.red.sandbox' part and you might as well have the hostname be as compact an encoding of the last /64 of the IPv6 address as possible.