Resumo

  • O RFC 2097 fazia o sistema remoto pedir que o par adicionasse nomes NetBIOS específicos. Uma mesma negociação podia aceitar alguns nomes e devolver erros distintos para outros.
  • O NBFCP também expunha a classe do par, a cadência e prioridade do multicast e a possível exigência de um cabeçalho IEEE MAC de doze octetos.
  • Opened e Added=0 eram evidências locais. Não provavam unicidade global, identidade, autorização, conectividade entre LANs, entrega completa, êxito posterior da sessão nem segurança.

Um enlace de acesso remoto pode estar eletricamente ativo, ter concluído o LCP e já ter entrado na fase de protocolos de rede do PPP, enquanto o nome exigido por uma aplicação ainda não existe na rede oposta. O RFC 2097 tornou essa lacuna observável.

Publicado em janeiro de 1997, o PPP NetBIOS Frames Control Protocol atribuiu 0x803f ao controle NBFCP e 0x003f aos datagramas NBF. Sua topologia era deliberadamente estreita: um sistema final podia conectar-se a um par ou à LAN ligada a esse par. O protocolo não servia para unir duas LANs, devido às limitações dos nomes NetBIOS e aos mecanismos de defesa desses nomes.

Abrir o transporte e admitir os nomes eram eventos diferentes

O PPP separava etapas. O LCP estabelecia, configurava e testava o enlace; autenticação e medição de qualidade podiam vir depois. Pacotes NBFCP só eram permitidos na fase de protocolos de rede, e datagramas NBF apenas quando o NBFCP alcançasse Opened.

Para sistemas finais, o RFC 2097 ainda exigia Name-Projection. O solicitante listava os nomes NetBIOS de dezesseis octetos que o par deveria adicionar à rede remota e marcava cada um como único ou de grupo. Como o campo Length tinha apenas um octeto, cada opção comportava no máximo quatorze nomes; listas maiores precisavam de várias opções.

Não era uma afirmação genérica de compatibilidade NetBIOS. Uma estação podia depender de vários nomes para serviços ou funções diferentes. O par remoto precisava tentar dar presença local a cada um.

A aceitação parcial precisava permanecer visível

Se o receptor não conseguisse adicionar todos os nomes, tinha de responder com Configure-Nak contendo a lista completa. Added=0 identificava um nome adicionado; códigos não nulos separavam duplicidade na tabela local, tabela cheia, nome em uso no NetBIOS remoto, conflito detectado, definição por outro ambiente ou falta de recursos.

A lista funcionava como proposta e recibo. Dois nomes enviados juntos podiam terminar de maneiras diferentes. O solicitante deveria reenviar os nomes aceitos, mas podia encerrar o NBFCP se sua aplicação precisasse do conjunto integral. O sucesso parcial da rede não decidia a utilidade do nome ausente.

O tempo também compunha a evidência. Adicionar nomes costumava levar cerca de três segundos, o mesmo valor que o temporizador padrão de reinício do PPP. O RFC recomendou dez segundos durante essa configuração. Uma retransmissão precoce podia medir a impaciência do controle, não a ausência do remoto.

Assim, Added=0 sustenta apenas uma frase precisa: nesse intercâmbio, esse par informou que conseguiu adicionar esse nome. Não prova uma visão coerente em todos os segmentos, servidores de nomes ou pontes. O RFC 1001 já reconhecia que falhas podiam deixar dados de nomes inconsistentes.

A classe declarada pelo par não autenticava sua identidade

Peer-Information permitia informar classe de implementação, versões principal e secundária e um nome opcional. As classes iniciais distinguiam gateway NetBIOS sobre PPP, servidor somente de acesso local, ponte NBF e sistema final.

Essa distinção mudava a superfície operacional: uma ponte não oferecia a mesma coisa que um servidor incapaz de encaminhar pacotes. Mas a opção era recomendada, não obrigatória, e os valores vinham do próprio par. O RFC não os vinculava criptograficamente a uma máquina, organização ou operador verificado.

A política de multicast podia ocultar um serviço alcançável

Algumas aplicações NetBIOS dependiam de multicast; outras não. Multicast-Filtering negociava um período máximo de encaminhamento e um bit de prioridade. Zero solicitava todos os pacotes. Um valor comum, limitado a sessenta segundos, definia a frequência máxima. 0xFFFF expressava valor desconhecido ou inexistente conforme estivesse em Request ou Nak. A prioridade escolhia entre multicast e pacotes dirigidos.

A política de banda passante virava comportamento da aplicação. O enlace podia estar aberto, os nomes projetados e o tráfego dirigido funcionando, enquanto um programa dependente de anúncios frequentes parecia quebrado. Concordar com um período descrevia o tratamento do par; não garantia a chegada de cada multicast.

Doze octetos mudavam o formato admissível

Pacotes NBF apareciam com cabeçalhos 802.3 Ethernet, 802.5 Token Ring, DIX Ethernet e FDDI. Algumas implementações PPP precisavam do cabeçalho completo para fazer bridging, outras apenas dos endereços IEEE e certos gateways de nenhum campo MAC.

IEEE-MAC-Address-Required expressava essa dependência. Por padrão não havia cabeçalho MAC. Se a opção fosse aceita, cada datagrama começaria com doze octetos de endereços de destino e origem. Como a decisão ocorria depois da negociação da MRU pelo LCP, o receptor tinha de aceitar pacotes NBF doze octetos maiores que a MRU.

O número da camada inferior não era o contrato inteiro do pacote. Observar o cabeçalho comprovava o formato usado, não que uma ponte o encaminhara ou que o destinatário nomeado o recebera.

Opened era permissão, não certificado de resultado

As quatro opções separavam fatos que um painel costuma reduzir a uma luz verde: nomes admitidos, função declarada do par, tratamento de multicast e formato de quadro. Opened autorizava NBF naquele enlace sob esses termos.

O RFC não acrescentava segurança. A seção correspondente dizia que questões de segurança não eram discutidas. O NBFCP não autenticava pessoas ou máquinas, não autorizava nomes, não cifrava dados nem provava integridade. Ao excluir o uso LAN a LAN, a própria especificação preservou a diferença entre projeção local e uma rede roteada geral.

A IANA ainda registra os valores de controle e dados, as quatro opções, os códigos de resultado e as classes de par. A permanência comprova identificadores estáveis, não implantação atual ou conformidade de produtos. A ausência de errata também não mede interoperabilidade.

A comparação com o RFC 1088 mostra a diferença. O RFC 1088 derivava mecanicamente um nome NetBIOS de um endereço IPv4. O RFC 2097 não criava o nome: levava um conjunto escolhido pelo par até um ponto remoto de admissão e retornava um resultado para cada entrada.

Lido pelo quadro posterior de Lu Heng sobre especificação mínima e primazia do código em operação, o NBFCP parece uma camada comum limitada aos compromissos necessários à interoperabilidade. É uma leitura editorial, não prova da intenção do autor do RFC. O fato histórico basta: quando nomes, função do par, multicast e formato do quadro ganharam recibos separados, enlace aberto deixou de significar acesso concluído.

Fontes