Resumo

  • O RFC 1293, da trilha de padrões e publicado em janeiro de 1992, acrescenta o Inverse Address Resolution Protocol ao ARP para solicitar o endereço de protocolo associado a um endereço de hardware conhecido. O caso Frame Relay parte de um DLCI de PVC estabelecido cujo endereço de protocolo remoto falta.
  • Uma solicitação InARP não é difundida, pois seu endereço de hardware de destino já é conhecido. A estação receptora pode responder ou ignorar a solicitação se não puder ou não quiser responder; uma resposta pode completar a tabela ARP local, mas a informação pode envelhecer ou ser invalidada.

O RFC 1293 começa por uma incompletude bem definida. A sinalização pode anunciar um novo circuito virtual e o seu Data Link Connection Identifier. Esse DLCI identifica uma conexão virtual através da WAN e serve, no exemplo Frame Relay, como equivalente de endereço de hardware. A própria notificação, porém, não traz o endereço de protocolo da estação do outro lado. Sem nova configuração ou uma forma de descobri-lo, a estação não consegue endereçar o outro lado por aquele circuito.

Não é correto transformar essa frase em um diagnóstico maior. O circuito não foi declarado inexistente, inseguro, configurado corretamente ou útil para toda finalidade. A especificação apenas separa uma alça de camada de enlace de um endereço de camada de protocolo ainda desconhecido. InARP cria um caminho para perguntar; não permite que a estação derive uma identidade remota do DLCI.

A descoberta começava com um vazio preservado

O funcionamento básico usa o formato ARP. A estação solicitante inclui os seus endereços de hardware e protocolo, o endereço de hardware alvo já conhecido e preenche com zero o campo de endereço de protocolo alvo. Depois encapsula o pacote para a rede específica e o envia diretamente ao destino.

O zero é uma afirmação disciplinada de que o dado ainda não foi aprendido. A requisição sabe onde colocar a pergunta, mas não presume a resposta. Essa diferença explica por que InARP não transmite em broadcast. O hardware de destino já é conhecido; não há procura por qualquer estação que possa se declarar dona de um endereço. A entrega é direta, mas a informação solicitada continua incerta.

O RFC observa que esse desenho pode ser mais eficiente que simular broadcast com muitas cópias da mesma mensagem e mais flexível que depender de configuração estática. Eficiência não muda a natureza da evidência. Uma mensagem direta não demonstra que o destino suporta InARP, tem endereço apropriado, está acessível, está disposto a responder ou manterá a mesma relação depois. Ela registra uma pergunta feita a um destino de hardware conhecido.

Nem todo protocolo com “reverse” respondia à pergunta certa

InARP inverte a direção da resolução: parte de um endereço de hardware e pede o endereço de protocolo correspondente. Os códigos de operação são 8 para solicitação e 9 para resposta. Reverse ARP foi considerado, mas não resolvia o problema, porque sua resposta traz o endereço de protocolo da estação solicitante, enquanto aqui se queria aprender o endereço da estação que recebe o pedido do outro lado do circuito.

O objeto da resposta é parte do contrato. Uma operação que informa “meu endereço” não substitui uma operação que informa “o endereço deste destino conhecido”. O RFC também não se limitou a mecanismos próprios de IP porque buscava resolver endereços de vários protocolos. Portanto, InARP não é uma autoridade de roteamento, um cadastro de proprietário IP ou uma confirmação universal de vizinhança. É uma troca situada entre uma identificação de hardware conhecida e um endereço de protocolo ausente.

Responder ainda dependia do outro lado

Ao receber uma solicitação InARP, uma estação pode colocar o mapeamento de endereço de protocolo e hardware do solicitante no próprio cache ARP. Pode formar uma resposta usando os endereços fonte da solicitação como endereços alvo da resposta. Mas, se não puder ou não quiser responder, ela ignora o pedido.

O silêncio não deve ser reescrito como sucesso parcial. Uma captura de solicitação mostra que uma estação a enviou; não mostra que o par foi encontrado, que estava configurado, que uma política permitiu responder ou por que a resposta não veio. O RFC não atribui uma causa a esse silêncio. Transformá-lo em falha de rede, identidade inexistente ou negação de acesso acrescentaria fatos que o protocolo não observou.

Quando uma resposta chega, o solicitante pode completar a entrada de tabela ARP e usar o endereço fornecido. Esse é um fato local e condicional: uma resposta foi recebida e a máquina pode guardar a relação. Não é uma certificação do endereço, nem uma prova de autorização ou de que dados posteriores chegarão a um serviço útil.

O cache conservava uma observação, não uma identidade eterna

O RFC diz expressamente que informações aprendidas por InARP podem envelhecer ou ser invalidadas. A entrada de cache, assim, deve carregar data e proveniência. Qual DLCI ou endereço de hardware estava no pedido? Qual estação respondeu? Qual endereço foi escolhido? Quando foi escrito? Por que e quando foi removido? Sem essas perguntas, uma linha local parece uma verdade duradoura sobre topologia e par remoto, embora a especificação nunca lhe dê esse estatuto.

O envelhecimento separa uma resolução passada de uma garantia presente. Mesmo uma entrada ainda não envelhecida não demonstra que o PVC continua em uso, que o host remoto mantém a configuração, que uma rota IP existe ou que o tráfego foi aceito. Cada uma dessas afirmações exige uma observação posterior. O efeito importante do cache não é encerrar a cadeia de evidência, mas fornecer um ponto explícito onde a cadeia pode ser revisada ou interrompida.

Essa cautela vale também para segurança. O RFC 1293 declara que questões de segurança não são abordadas. Nenhuma resposta InARP, por si, prova autenticação, integridade, autorização ou proteção contra ataques. A possibilidade de guardar uma associação não transforma o mecanismo de descoberta em um mecanismo de confiança.

Hosts com vários endereços não podiam devolver qualquer um

Um host com vários endereços de protocolo em uma interface precisa olhar o endereço de protocolo do solicitante e responder com um endereço correspondente à rede desse solicitante. Se, no exemplo IP, não tiver um endereço de interface no sub-rede requisitada, não deve responder. Também pode haver uma solicitação para cada endereço da interface, e o lado receptor pode responder a alguns ou nenhum conforme a configuração.

O mapeamento correto é, portanto, relacional. A frase “o outro lado tem vários endereços” não informa qual cabe nesta consulta. A resposta depende de quem pergunta, de qual rede aparece no pedido e da configuração de quem responde. Essa regra impede que uma lista de endereços se torne uma substituta para uma associação observada.

Fonte e limites da evidência

Este artigo usa RFC 1293 — Inverse Address Resolution Protocol. Ele sustenta o estatuto de padrão e a data de janeiro de 1992, a motivação DLCI/PVC, o endereço remoto ausente, a rejeição de RARP e de mecanismos apenas IP, os códigos e formato InARP, o pedido direto não difundido, a resposta ou silêncio, o cache, envelhecimento ou invalidação, a seleção multiendereço e a afirmação de que segurança não é tratada.

Não sustenta uma implantação Frame Relay concreta, um DLCI atual, um host alcançável, uma configuração, uma resposta correta ou autorizada, persistência de cache, rota IP, entrega de pacote, propriedade de segurança ou resultado para usuário. Ler um DLCI conhecido como condição para investigar, e não como vizinho utilizável já provado, é uma inferência editorial limitada pelo mecanismo.