Original text:
There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes <del> Unencrypted Resolvers on non-public IP addresses whose identity cannot be confirmed using TLS certificates. </del>  Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address <del> of the Unencrypted Resolver, and that IP address is a private address (such as those defined in RFC1918).  This approach can be used for DoT or DoH. If the IP addresses of the Encrypted and Unencrypted Resolvers are not the same, or the shared IP address is not a private IP address, the client MUST NOT use the Encrypted Resolver opportunistically. </del>  5.

Reviewer comments:
The document was inconsistent, with the authenticated section saying same IP addresses MAY use opportunistic, but the opportunistic section saying the same IP address exception was for private IP addresses only.
Forgot to mention this is to address issue
From Eliot Lear: Can you explain the following statement? and that IP address is a private address (such as those defined in [RFC1918] I ask because it appears that you are using private addresses as some sort of security property. I recommend against that, not least of which is that end systems that are likely to deploy this stuff will have a wide ranging mishmosh of addressing plans, and of course, private network addresses don’t really have any positive security properties to speak of. The only aspect I can see is that one really has to be quite careful of including private network addresses in certificates. Of course, public trust anchors won’t allow it, but even private ones will have some difficulty. Your average bank might have multiple overlapping zones of trust - it’s a pretty hairy scene.
The intent of that section is to say that "if you were going to send this local IP address unencrypted traffic anyway, using encryption to that same IP address is a net improvement to the threat model." It certainly was not meant to imply that private addresses could be verified via the TLS cert SAN mechanism used for public addresses. I can try to rephrase this section to be more accurate. Please comment again if I missed the point.
In reviewing the opportunistic section, I see what you mean Eliot. The need to use "private IP" as a feature is not necessary since same-IP opportunistic discovery is permitted whether the address is private or not. However, the draft conflicted on that point. I have a PR to remove the local IP address as a decision branch and make the draft consistent.
With the PR merged, I am closing this issue.

Revised text:
There are situations where authenticated discovery of encrypted DNS configuration over unencrypted DNS is not possible.  This includes  <ins> Unencrypted Resolvers on non-public IP addresses such as those defined in RFC1918 whose identity cannot be confirmed using TLS certificates. </ins> Opportunistic Privacy is defined for DoT in Section 4.1 of RFC7858 as a mode in which clients do not validate the name of the resolver approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address  <ins> of the Unencrypted Resolver.  This approach can be used for any encrypted DNS protocol that uses TLS. </ins> 5.