rpcbind é um análogo aproximado do BIND ou, na verdade, de qualquer servidor DNS. Se bem me lembro, você escolhe ou recebe um número de protocolo quando compila a declaração da interface RPC no código stub do servidor e do cliente com rpcgen .
Quando um cliente se inscreve em uma determinada interface em um determinado host, geralmente com uma chamada clnt_create() , o código stub pergunta a rpcbind nesse host uma pergunta, algo como "em qual porta UDP ou TCP é o número do protocolo X ouvindo? rpcbind , diferentemente da maioria dos outros serviços ONC, escuta na porta TCP e UDP 111, então, dado um nome de host ou endereço IP, um programa pode apenas perguntar a rpcbind nesse host ou endereço IP. rpcbind responde com o número da porta apropriado, se um servidor tiver se registrado com ele nesse host. Esse registro é feito pelo processo do servidor quando ele chama svc_create() .
No seu exemplo, o 100003 é o número do protocolo do NFS. Alguns processos foram registrados com rpcbind , fornecendo seu número de protocolo (100003) e qualquer porta TCP ou UDP que eles adquiriram. É até rpcbind para dar corretamente esse número de porta, 2049 no seu caso, para qualquer chamada sobre ele para "qual porta devo usar para o número de protocolo 100003".
Agora estamos entrando em território mais estranho. O "0.0.0.0.8.1" está na coluna "endereço" de rpcinfo output. Como esse é o "endereço universal" do processo do servidor NFS, aposto que o prefixo "0.0.0.0" é o endereço IP (INADDR_ANY neste caso) que o servidor usou na chamada do sistema bind() ao obter um número de porta. Eu não tenho certeza do que é o sufixo "8.1", mas olhando para rpcinfo output, ele tem que ter algo a ver com o servidor NFS sendo basicamente um thread do kernel.