RPCINFO on macOS behaves different compared to other linux clients and doesn't provide request address in rpcb structure of the RPCBPROC_GETADDRLIST call which doesn't seem to be forbidden.
In this case RPCBIND uses RPC call's source address and picks a closest corresponding local address.
Though if there are no addresses in the same subnet as the source address, return of RPCBIND may vary depending on the order of addresses returned in getifaddrs.
If a link local precedes global address it may be returned even if request comes neither from a link local nor from link local in a different scope, which will prevent services like nfs from working in tpc6 scenario on macOS clients.
Issue can be seen only on FreeBSD rpcbind port due to changes in workflow of addrmerge call.