Resumo

  • A RFC 1220 só permitia tráfego LAN depois que o Bridge Network Control Protocol abrisse a conexão. Open era um pré-requisito do protocolo, não uma confirmação de entrega.
  • O resultado ainda dependia do MRU, da ordem em linhas paralelas, dos tipos MAC, da direção da compressão, de LAN ID, do spanning tree e do tratamento do FCS.
  • O CRC de PPP e o FCS opcional da LAN protegiam registros diferentes. Uma moldura aceita na linha ponto a ponto não provava preservação do quadro LAN original nem sua emissão na rede remota.

O controle chegou primeiro, como deveria

A RFC 1220, Point-to-Point Protocol Extensions for Bridging, foi editada por F. Baker e publicada em abril de 1991. O RFC Editor e o IETF Datatracker a registram como Proposed Standard do fluxo IETF e hoje indicam obsolescência pela RFC 1638. Esse histórico descreve documentos, não uma rede em operação.

A especificação queria transportar quadros de LAN entre pontes remotas por uma ou mais linhas seriais. Ela partia da disciplina PPP da RFC 1171 e assumia que os dispositivos tinham concordado em usá-la. Também admitia que estivessem dispostos a usar a linha para bridging. As duas condições eram pressupostos do modelo; não havia evidência de uma negociação real.

BNCP colocava a próxima trava. Seus pacotes aguardavam LCP alcançar a fase de configuração dos protocolos de rede. Depois, o tráfego LAN só podia ser trocado quando BNCP estivesse Open. A ordem era importante: primeiro se configura e habilita a ponte, depois entram os dados.

Ainda assim, Open dizia apenas que a máquina de estados permitia iniciar. Não identificava um quadro enviado, uma entrada de forwarding, uma porta de saída, a emissão na LAN distante nem uma resposta da aplicação.

O silêncio do peer era uma convenção estreita

Para transparent bridging, a RFC assumia permissão quando o vizinho recebia BPDUs IEEE 802.1 e não respondia com Protocol-Reject de PPP. Dentro daquele modelo, a ausência de rejeição tinha um significado protocolar.

Ela não virava autorização institucional. Não nomeava o operador, não provava configuração igual nos dois lados e não mostrava convergência do spanning tree. Um administrador podia inclusive separar domínios de árvore; para isso, precisava configurar ambos os extremos para não trocar BPDUs. Uma ponte nesse modo descartava silenciosamente um BPDU inesperado.

Assim, o mesmo silêncio visível podia vir de aceitação, isolamento intencional ou falha unidirecional. A RFC recomendava Magic Number para detectar loopback e monitoramento de qualidade porque o tráfego normal de spanning tree era em grande parte unidirecional. Ausência de retorno não era um teste completo do caminho de volta.

Opções podiam documentar uma incompatibilidade

BNCP negociava tipos MAC, compressão tinygram, identificação de LAN e números de anel/ponte. O anúncio MAC informava o que o receptor estava preparado para servir. Quando havia anúncio, tipos omitidos seriam descartados. Sem anúncio, o peer podia presumir suporte amplo, embora o receptor ainda descartasse o que não entendesse.

Um Configure-Reject podia deixar uma situação ainda mais clara e ainda assim perigosa: o transmissor continuaria encaminhando um tipo que o receptor já sinalizara que descartaria. A troca de controle registrava a incompatibilidade, mas não necessariamente impedia a perda.

A compressão era direcional. Um lado podia descomprimir e o outro não; sem negociação, não havia compressão. Por isso o estado precisava ser registrado por sentido.

LAN Identification era consultivo e vinha desativado. Habilitado, dizia que talvez houvesse LANs rotuladas além do peer e que ele estava preparado para atendê-las. Desativado, dizia que esse tráfego seria descartado. O parâmetro orientava o envio, mas não comprovava identidade organizacional, autorização ou saída por uma interface específica.

Open não aumentava o tamanho da linha

O MRU negociado precisava comportar os tipos MAC aceitos, pois não havia fragmentação e remontagem. Até Ethernet podia superar o MRU padrão de 1.500 octetos do PPP. A ponte podia estar Open e não conseguir transportar uma classe válida de quadros.

Linhas paralelas traziam outra obrigação. O transmissor precisava saber se o protocolo ponteado exigia a ordem original; sem essa certeza, devia preservar a sequência. Espalhar uma conversa para usar melhor a capacidade podia alterar uma propriedade esperada por protocolos desenhados para uma única LAN.

Havia também dois registros de integridade. O CRC da moldura PPP cobria o salto ponto a ponto. O FCS LAN opcional vinha do quadro originário. A RFC os descrevia como separados e não relacionados. Quando o FCS não vinha embutido, a saída para a LAN podia gerar outro. Integridade no enlace, preservação do quadro e entrega ao destino eram fatos distintos.

Cabeçalho não era evento de encaminhamento

As flags indicavam FCS, LAN ID, compressão de zeros e preenchimento da linha. O tipo MAC definia como interpretar os bytes seguintes. Esses campos não mostravam a tabela aprendida, o estado da porta no spanning tree ou a recepção pelo host.

As fontes não contêm configuração de operador, captura de BNCP, tabela MAC, trace de pacote ou log de aplicação. A seção de segurança informa que o tema não é discutido. Não há base para afirmar autenticação, autoridade, sigilo, implantação ou resultado.

O Open de BNCP era uma resposta correta para o começo do tráfego. O erro seria transformá-lo no recibo do fim do caminho.

Fontes