Resumo

  • RFC 3145 colocou uma causa específica de PPP no Call-Disconnect-Notify do L2TP, mas exigiu que ela fosse opcional, não obrigatória e apenas informativa.
  • Código, protocolo de controle e direção formam a coordenada de um relato; não comprovam sozinhos falha física, responsabilidade, leitura pelo usuário ou acerto contábil.
  • O desenho tornou o diagnóstico interoperável entre administradores diferentes sem entregar ao emissor autoridade sobre a conclusão.

O recibo que faltava entre o LAC e o LNS

O L2TP separava o transporte da sessão PPP dos detalhes internos da sessão. Um L2TP Access Concentrator recebia o acesso e encaminhava a sessão para um L2TP Network Server. A separação permitia que o túnel funcionasse de modo geral, mas também fazia com que a ponta remota recebesse uma notificação de encerramento sem o último estado PPP.

Os Result Code e Error Code de L2TP descreviam a camada de controle do túnel. Eles não diziam necessariamente que LCP expirara, que nenhum NCP chegara a Opened, que os lados discordaram sobre endereços ou que uma política administrativa encerrara o enlace. A organização diante do usuário podia não ser a organização que possuía esse diagnóstico.

RFC 3145 definiu o PPP Disconnect Cause Code AVP, Vendor ID 0, tipo 46. Ele só era válido no Call-Disconnect-Notify. O valor reunia um código, o número do protocolo de controle PPP, uma direção e texto UTF-8 opcional. Pela primeira vez, a notificação podia levar uma descrição estruturada da camada encapsulada.

O novo recibo não substituía os códigos L2TP. O RFC mandava usá-los em conjunto. “A chamada foi removida por este resultado de controle” e “este peer observou esta condição PPP” continuavam sendo afirmações diferentes. Um modelo que conserva apenas uma causa final perde a discordância que deveria investigar.

Opcionalidade como limite de poder

O bit Mandatory do AVP tinha de ser zero. Um peer sem suporte podia ignorar a informação e ainda processar o encerramento. Isso mantinha a interoperabilidade, mas também impedia que o diagnóstico virasse uma exigência escondida para a função principal.

O documento foi igualmente claro sobre efeito: o AVP servia para informação e registro, sem alterar o túnel ou a sessão PPP. A máquina de estados decidia o ato; uma ponta descrevia sua observação; a investigação posterior decidiria quanto confiar nela. RFC 3145 não transferia os três poderes junto com o campo.

O bit Hidden podia proteger o atributo dentro dos mecanismos L2TP, e RFC 3193 depois descreveu L2TP sobre IPsec. Um canal protegido sustenta origem, integridade e confidencialidade. Ele não prova que o observador enxergou toda a cadeia causal. Autenticar quem fala é diferente de certificar o que foi dito.

Direção é perspectiva, não culpa

Direção zero indicava erro global; um, “no peer”; dois, “no local”. Local e peer eram definidos a partir do host que montava o AVP. Quando um sistema troca esses termos por “cliente” e “operadora”, ele introduz papéis comerciais que o pacote não transportou. Quando troca por “culpado” e “vítima”, introduz ainda mais.

A direção era necessária para interpretar ações. Na desconexão normal, dizia qual lado enviou LCP Terminate-Request. Em criptografia ou callback compulsórios, distinguia quem exigiu e quem recusou. Em negociação de autenticação, separava os protocolos locais rejeitados pelo peer dos protocolos pedidos pelo peer que o lado local não aceitava. Recusar uma opção pode ser a política correta; iniciar o último passo não explica os anteriores.

O número de protocolo preservava outro eixo. Erros globais usavam zero; erros de enlace apontavam LCP; erros de autenticação, o protocolo usado; erros de rede, o NCP relacionado. Quando vários NCPs falhavam, vários AVPs podiam aparecer. Um único AVP deveria identificar o fracasso mais recente, não declarar que ele fora o único ou o principal.

“Código 16” isolado é, portanto, evidência empobrecida. O registro forte preserva peer, túnel, sessão, CDN, instante, proteção, protocolo e direção. O valor oficial só se torna útil quando suas coordenadas sobrevivem à ingestão.

A taxonomia parava antes da verdade total

Os códigos iniciais, de 0 a 20, incluíam nenhuma informação, desconexão administrativa, término normal, timeout de máquina de estados, ausência de pacotes LCP reconhecíveis, possível loop por Magic Number, timeout de Echo Request, divergências de Multilink PPP, recusa de callback ou criptografia, falhas de autenticação, falta de NCP disponível e incapacidade de convergir em endereços.

Dois produtos podiam enfim nomear a mesma classe de ocorrência. Mas classe não é cadeia causal. Um echo timeout é compatível com perda, congestionamento, caminho de retorno bloqueado, peer inativo ou processo local travado. Uma falha de autenticação é o resultado de um diálogo, não a prova pública de qual credencial estava correta.

O RFC advertiu que extensões futuras não deveriam revelar ao atacante que o nome estava certo e apenas o segredo errado. Uma distinção aparentemente útil para suporte vira oráculo sob consultas repetidas. A especificação mínima tinha de equilibrar depuração com o que jamais deveria atravessar o túnel.

O texto UTF-8 opcional também não se tornava verdade por ser legível. Ele podia ser exibido ou registrado, mas nada garantia que chegara a um usuário, que era adequado àquele público ou que fora traduzido sem alterar o sentido. Texto original, versão localizada e tupla estruturada precisam de recibos separados.

A transição do identificador de fornecedor

Um rascunho havia usado Vendor ID 43, da 3Com. RFC 3145 permitiu que receptores aceitassem a forma antiga como equivalente, mas recomendou que emissores não a usassem. A compatibilidade preservava o passado; a atribuição IETF definia o caminho de envio futuro.

Esse episódio marca a função correta de um registro. IANA mantém a associação entre valor e significado. Isso autoriza decodificação, não garante implantação nem veracidade de cada evento. O peer é a fonte do relato; o registro fornece vocabulário; o estado PPP e o tráfego fornecem a possibilidade de contestação.

Contabilidade não cabia no mesmo campo

O RFC dizia que a causa podia ajudar contabilidade e depuração. Para contabilidade de túnel, RADIUS mantinha outros atributos e outra sequência: identificação, início, atualizações, parada e contadores. O código PPP pode indicar por que uma parada ocorreu. Não prova que o Stop foi recebido, que os contadores fecharam ou que uma cobrança foi apurada corretamente.

O plano de dados também precisa falar. Echo timeout deve ser comparado a contadores, alarmes e testes de caminho. Falha de autenticação precisa ser confrontada com estados sem espalhar segredos. Término normal pede o intercâmbio LCP correspondente. O código escolhe a gaveta; não fabrica o conteúdo dela.

A experiência do usuário está em uma quarta trilha. Gerar uma frase, entregá-la e alguém lê-la são acontecimentos distintos. A presença de texto no AVP não prova os dois últimos.

Um pequeno protocolo para manter as camadas honestas

RFC 3145 não é historicamente importante por ter encontrado vinte e uma explicações definitivas. Ele importa porque fez um mínimo interoperável sem deixar o símbolo dominar a operação. O código é linguagem comum; o CDN é um ato registrado; PPP e pacotes são funcionamento; accounting e experiência são consequências.

Sistemas modernos ainda transformam o reason de um componente em “causa do incidente”, depois de remover emissor, direção e incerteza. A arquitetura de 2001 foi mais adulta. Uma causa podia atravessar o túnel. A autoridade para julgar o mundo não atravessava com ela.

Fontes