Resumo

  • O DRAP trocou um par DLSw por estação por muitos clientes leves, um servidor e uma única relação DLSw com o centro.
  • O servidor atribuía ou guardava endereços MAC, respondia consultas de alcance, negociava capacidades, criava identificadores e preservava circuitos durante a suspensão do TCP.
  • Esses sinais não provavam identidade humana, autorização, procedência autêntica ou entrega ponta a ponta; a RFC 2106 não definiu autenticação e era Informational, não um padrão da Internet.

O estado foi agregado, não eliminado

A RFC 2106 partiu de um problema de escala. Se cada estação remota executasse DLSw completo, o número de sessões TCP até o centro cresceria com o número de estações. Um protocolo entre comutadores terminava instalado em cada equipamento do usuário.

O DRAP redesenhou a hierarquia. As estações viraram clientes de um servidor próximo; somente o servidor manteve o vínculo DLSw com o roteador central. Muitas conexões de borda passaram a compartilhar uma relação de backbone. A complexidade não sumiu: migrou para o gateway que lembrava e falava pelas estações.

Essa é a fronteira editorial. A RFC 1434 tratou de dois enlaces LLC locais sobre um transporte comum; a RFC 2024 expôs diretório, cache, transporte e circuito DLSw em uma MIB; a RFC 2043 separou duas admissões SNA em PPP; a RFC 2097 tratou de nomes NetBIOS individuais. A RFC 2106 fez do servidor a memória e a autoridade operacional de muitos clientes.

MAC virtual servia ao encaminhamento

Uma estação ligada por PPP podia ter IP, mas não MAC de LAN. O servidor DRAP podia atribuir uma MAC virtual. Se o cliente apresentasse um endereço diferente de zero, o servidor verificava sua exclusividade e o armazenava. Para sessões iniciadas pelo servidor, o cliente podia registrar previamente MAC e IP.

O endereço localizava um ponto no modelo. Não dizia qual pessoa controlava a estação, se havia autorização para usar uma aplicação ou se o registro vinha de fonte autêntica. O cache guardava uma alegação operacional, não uma identidade verificada.

Com vários servidores configurados, o cliente enviava pedidos e usava o primeiro a responder. A primeira resposta mostrava disponibilidade e latência naquele instante, não legitimidade administrativa.

Cada resposta tinha alcance limitado

CAN_U_REACH perguntava; I_CAN_REACH trazia a afirmação do servidor. START_DL pedia uma estação de enlace; DL_STARTED informava sua criação. Identificadores de origem e recepção distinguiam circuitos. A troca de capacidades acertava MAC, suporte a NetBIOS, SAPs e a possibilidade de ouvir uma nova conexão TCP.

Uma resposta positiva provava que o servidor afirmava alcançar o destino. Não provava entrega à aplicação. Um enlace iniciado mostrava uma transição local, não autorização. Um identificador nomeava estado interno, sem validar sua procedência de forma independente.

A RFC 2106 usava uma conexão TCP bidirecional por par cliente-servidor na porta 1973. O TCP podia ser suspenso e os circuitos de enlace permanecer. Com novos dados, o cliente se reconectava sem repetir a troca de capacidades. Keepalives opcionais mediam resposta; após três falhas, a recomendação era fechar TCP e circuitos.

Assim, “conectado” tinha camadas. Um socket podia desaparecer e o circuito lógico continuar. Um keepalive demonstrava resposta, não a chegada de uma transação ao destino final.

Informational não significava consenso normativo

Publicada em fevereiro de 1997, a RFC 2106 era Informational e dizia não especificar um padrão da Internet. Não descrevia autenticação nem trazia uma seção Security Considerations. Era uma especificação de acesso remoto e transições de estado, não uma arquitetura de identidade.

A RFC 2114 tornou-a obsoleta no mesmo mês, renomeou o sistema como DCAP e adicionou descoberta, preservando o núcleo cliente-servidor. Uma porta registrada, uma implementação interoperável ou um número RFC podem tornar um sistema operável. Nenhum deles, sozinho, comprova consenso duradouro.

Fontes