Resumo

  • A RFC 1088, STD 48, encapsula datagramas IP em datagramas NetBIOS e obtém o nome de destino IP.XX.XX.XX.XX diretamente do endereço IP.
  • A derivação dispensa uma consulta de endereço físico nesse suporte. Ela não estabelece rota, propriedade, identidade, multicast IP, alcance atual ou aceitação da carga útil.

Há uma diferença entre tornar um endereço soletrável e tornar um destino conhecido. RFC 1088 escolhe a primeira tarefa. Para aplicações IP, um nome NetBIOS de até dezesseis bytes recebe o prefixo IP. e as representações hexadecimais ASCII de cada byte do endereço. O IP datagram é tratado como dado do datagrama NetBIOS, enviado para esse nome ou para o nome de grupo de broadcast.

O documento observa que não é preciso um mecanismo de consulta de endereço físico, como ARP, porque o nome NetBIOS já é um mapeamento do endereço IP. É uma economia real de coordenação. Mas ela tem um objeto pequeno: obter o nome NetBIOS definido pelo próprio padrão. Nenhuma consulta de hardware é necessária para essa operação; disso não se segue que tenha sido determinada uma rota, uma interface física em funcionamento ou a responsabilidade sobre o endereço.

RFC 791 oferece a disciplina conceitual que evita esse salto. Nome, endereço e rota não são sinônimos. A RFC 1088 pega um endereço IP e o converte em um rótulo de entrega no serviço de datagramas NetBIOS. A regra não informa o próximo salto. Tampouco diz se o host recebeu o pacote, se o programa o aceitou ou se a pessoa que o observa tem autorização para agir sobre aquele recurso.

Registrar, receber, renovar, remover

O estado que a especificação pede é explícito. Durante a inicialização, o host adiciona à tabela de nomes o nome IP.XX.XX.XX.XX correspondente ao seu endereço e o grupo IP.FF.FF.FF.FF. Depois submete pedidos de recepção de datagramas para os dois. Quando um datagrama chega, a pilha o processa e submete outro pedido. No encerramento, cancela as recepções pendentes e elimina os nomes adicionados.

Não há nessa sequência uma tentativa de descobrir onde um host está escondido numa topologia. RFC 950 ajuda a marcar a diferença: em sub-redes transparentes, pontes podem interceptar consultas ARP, descobrir em qual LAN está o alvo e manter caches que crescem com essa descoberta. A RFC 1088 não monta tal mecanismo. Ela fixa o nome ao qual o datagrama deve ser apresentado no seu próprio portador.

Também por isso seria errado descrever o padrão como “ARP substituído”. RFC 826 trata, no contexto Ethernet, da resolução entre endereço de protocolo e endereço Ethernet. A RFC 1088 afirma apenas que, na convenção NetBIOS escolhida, o IP já produz o nome de datagrama necessário. Uma resolução não ocorre; não desaparecem por isso a topologia, a política de encaminhamento ou a incerteza sobre o destino.

O que o grupo de broadcast não promete

Para broadcast IP, o nome de grupo é IP.FF.FF.FF.FF. O texto logo adiciona a fronteira que uma leitura rápida perde: não há tentativa de suportar endereços multicast IP por nomes de grupo NetBIOS. A existência de um grupo de broadcast não pode ser usada para alegar uma semântica geral de multicast.

Há ainda o teto de 512 bytes. Esse é o maior dado de um datagrama NetBIOS e, portanto, o MTU do IP sobre NetBIOS. Hosts que se comuniquem com esse ambiente talvez tenham de remontar datagramas fragmentados. O nome derivado, o datagrama transmitido, os fragmentos e a remontagem precisam aparecer como etapas distintas em registros operacionais. Comprimir tudo em “destino confirmado” torna o diagnóstico impossível.

Por fim, a referência ao roteador é condicional. Um roteador que consiga encapsular IP tanto em protocolos de enlace ordinários quanto em datagramas NetBIOS permite que esses hosts se comuniquem com a Internet mais ampla. A RFC descreve a consequência daquela capacidade. Não atesta que um roteador particular existia, que havia uma rota em produção ou que um endereço possuía alcance e autoridade.

A sobriedade é a lição. A RFC 1088 eliminou uma pergunta local ao fazer o nome nascer do endereço. Não permitiu que o nome passasse a falar em nome da rota, do proprietário ou da aplicação.

Fontes e limites

As fontes sustentam a encapsulação de 1989, a regra de nome, o ciclo de recepção, os limites de broadcast/multicast e MTU, e as distinções com IP, subnetting e ARP. Elas não sustentam implantação atual, configuração de um host, propriedade, identidade, autorização, rota observada, entrega ou sucesso de aplicação.