Resumo

  • A RFC 1613 exigia uma conexão TCP separada para cada circuito virtual X.25. O Logical Channel Number em XOT era arbitrário e não distinguia chamadas com o mesmo número em streams diferentes.
  • A camada XOT entregava a identidade do stream ao mecanismo X.25; na saída, a interface local aplicava seu próprio LCN. A identidade operacional estava no mapeamento, não num campo portátil.
  • Parâmetros explícitos de fluxo, pacotes que permaneciam locais e o setup adicional de PVC repetiam a separação entre regra compartilhada e decisão local comprovável.

Dois valores corretos, uma chave errada

No exemplo do RFC, A e B abrem sessões XOT com C e usam o mesmo LCN. Se C procurar o estado apenas por esse número, junta dois espaços locais legítimos. Um pacote pode cair na chamada errada; um Clear pode encerrar outro circuito.

A RFC 1613, cisco Systems X.25 over TCP (XOT), registra o caso. O RFC Editor a data de maio de 1994 e classifica como Informational, não como Internet Standard. Ela documenta um método, sem provar adoção geral.

Cada virtual circuit precisava de sua própria conexão TCP. O LCN interno não tinha significado determinante e podia ser arbitrário. O mecanismo X.25 de C precisava saber que os pacotes vinham de interfaces XOT lógicas distintas; a camada XOT, portanto, passava a identificação do stream.

O defeito não era falta de bits. Era a perda do escopo que tornava o identificador válido.

O stream completava o contexto

TCP surgia antes do circuito X.25. A RFC usava TCP 1998 e vedava dados XOT no SYN. O registro atual da IANA mostra x25-svc-port em 1998 para TCP e UDP. A linha coordena um valor; não comprova serviço, titular, conformidade ou tráfego. RFC 1613 descreve TCP.

Uma conexão por VC fornece endpoint e ciclo de vida para separar circuitos. Ainda assim, não autentica pessoa, autoriza chamada nem confirma resultado da aplicação.

O TCP histórico da RFC 793 entrega octetos ordenados, não limites de pacotes X.25. XOT acrescentou quatro bytes: Version e Length de 16 bits. Version diferente de zero ou comprimento ilegal exigiam fechar TCP.

Esse framing é contexto, não a nova tese. A RFC 1006 já recuperava registros TPDU em TCP com outro header de quatro octetos, tema já publicado por BTW. Em XOT, até um pacote perfeitamente delimitado pode ser ligado ao circuito errado se a interface/stream desaparecer do índice.

O número mudava na saída

Ao enviar para uma interface X.25 local, a implementação ajustava o LCN usado naquela interface. O número podia mudar enquanto o circuito pretendido continuava.

Um recibo confiável une conexão TCP, interface XOT, LCN de entrada, interface de saída e LCN de saída. Guardar só o número cria ambiguidade; guardar só endpoints TCP apaga a alocação local. A Running-Code Primacy limita a afirmação: o RFC fornece a regra mínima; configuração, transições e pacotes provam a instância. Não provam identidade social ou sucesso comercial.

Defaults não atravessavam sites diversos

X.25 podia usar packet size e window size de rede. Entre sites distintos sobre TCP/IP, a RFC exigiu que todo Call declarasse os dois. Aceitar uma chamada incompleta era local; se aceita, Call Confirm devolvia os valores efetivos.

Flow control podia ser end-to-end ou local. O modo local podia fragmentar ou juntar DATA e manter sequências diferentes por interface. Uma ligação modulo 128/8 precisava traduzir estado e reduzir uma janela grande demais ou recusar. RNR num sentido não parava necessariamente DATA no outro.

TCP confiável não provava janela compatível, receptor pronto, sequência correta ou transação concluída.

O que atravessava e o que ficava local

Interrupt e Reset mantinham alcance end-to-end. Restart, DTE Reject, Diagnostic e Registration tinham sentido local e não cruzavam XOT. Encapsular não tornou todo controle interno portátil.

PVCs, provisionados sem Call/Clear, exigiam setup não padronizado após TCP. Nomes de interface, LCNs locais e fluxo eram comparados. Os status separavam interface ausente/down, PVC inexistente, configuração ou fluxo incompatíveis. Sucesso zero exigia Reset local; fechar TCP quebrava o PVC. Uma colisão de setup jamais podia levar tráfego por duas conexões.

Esses estados descrevem execução, não identidade do contratante ou utilidade dos dados.

Limite da evidência

A seção de segurança diz apenas que não discute segurança. Silêncio não é proteção. As fontes não demonstram autenticação, criptografia, autorização ou prevenção de ligação incorreta.

Nenhuma implementação, release Cisco, operadora ou captura foi testada. IANA não prova serviço ativo. Não há medida de deployment atual, prevalência, incidente, resultado de aplicação ou linhagem direta para overlay moderno.

A conclusão firme é estreita: um campo pode ser válido e ainda não ter escopo para identificar o objeto operacional. RFC 1613 preservou no stream e na interface o limite que não cabia no número.

Fontes