Tom and I have been digging into this a little bit. It appears that some man pages (including Solaris 10) claim that for recvmsg, the msg_name field indicates where the *receiving* address should be recorded, rather than the sender's address as in current documentation. POSIX specs, glibc man pages, Linux 2.6.9 behavior, and Solaris 10 behavior all indicate that it is in fact the sender's address that's returned. And a peek at the 4.3BSD recvfrom source code suggests that perhaps never was implemented that way. So, the new code in the KDC seems to be okay. However, the RPC code we've got calls recvmsg with MSG_PEEK, thinking that it can get the local address, and then calls recvmsg to get the remote address and the data. I instrumented the RPC code in question, and on both Solaris and Linux I found that the so-called local address and the remote address indicated the same address and port. Which means (1) the RPC code is buggy, and (2) probably nothing currently using it cares. For a tiny bit of performance, we could kill the recvmsg call and always store 0.0.0.0. Or use IP_PKTINFO where it's available, but we still wind up with platforms where we can't tell, unless we switch to using a socket per local address like the KDC code does (when IP{,V6} _PKTINFO aren't available). Possibly we might be able to adapt the KDC code to implement the socket listening part of the RPC code, if we separate out the KDC- specific bits. (Even if we don't care about random RPC code, it might be worth doing for kadmind, krb524d, etc.) Ken