Resumo

  • A RFC 1473 separou configuração e operação de IP sobre PPP. Escrever open inseria um evento na máquina de estados IPCP; não atestava que ela havia alcançado Opened.
  • Alterar a preferência de compressão só teria efeito no próximo reinício. Antes da negociação, método e slots eram indefinidos; depois, ainda eram parâmetros, não recibos de pacote.

Publicada em junho de 1993, a RFC 1473 escolheu poucos objetos para o PPP IP Group. A MIB deveria conter o essencial para falha e configuração, demonstrar utilidade e evitar valores apenas deriváveis de outros.

Essa economia deixou à vista uma diferença que painéis costumam esconder: o que foi pedido, o que foi negociado e o que trafegou são fatos de camadas distintas.

Open era uma entrada na máquina

pppIpConfigAdminStatus expressava o estado imediatamente desejado. Definir open injetava o evento administrativo Open na máquina IPCP; close injetava Close.

O recibo da escrita confirmava que o agente aceitou a entrada. A camada inferior ainda podia faltar, o par podia não responder e as opções podiam ser rejeitadas. O próximo estado não pertencia ao gerente.

A RFC 1661 preservou NCPs independentes por protocolo de rede. Uma sessão PPP estabelecida ou outro NCP aberto não substituía o estado próprio de IP.

A preferência aguardava outra sessão

pppIpConfigCompression escolhia none ou compressão de cabeçalho TCP/IP de Van Jacobson como tentativa local. A RFC determinava que a mudança surtiria efeito quando o enlace fosse reiniciado em seguida.

O valor novo já existia na administração enquanto o enlace atual ainda podia operar com o anterior. Para provar ativação eram necessários a geração gravada, o reinício certo e a negociação que veio depois.

A RFC 1332 definiu IP-Compression-Protocol, desabilitado por padrão. Cada ponta tinha de pedir separadamente a capacidade de receber pacotes comprimidos para haver compressão nos dois sentidos. Uma direção não autorizava inferir a outra.

A tabela podia devolver um valor sem afirmar nada

O quadro operacional trazia pppIpOperStatus, protocolos de compressão local-remoto e remoto-local e os dois Max-Slot-Id. Esses campos só ficavam disponíveis após a negociação e a chegada a Opened.

Antes disso, o conteúdo era indefinido e o valor devolvido dependia da implementação.

Indefinido não quer dizer simplesmente atrasado. Um dado atrasado pertenceu a uma sessão anterior; um dado indefinido pode ser zero, memória residual ou inicialização sem qualquer compromisso semântico. O número cabe no tipo, mas não cabe numa conclusão.

Depois de Opened, a direção continuava indispensável. Se VJ não estivesse em uso, o slot seria zero. Antes de Opened, o mesmo zero não demonstrava acordo por “nenhuma compressão”.

Opened era permissão, não entrega

A RFC 1332 exigia a fase de protocolo de rede e IPCP Opened antes de comunicar IP. A RFC 1661 mandava descartar pacotes quando o NCP correspondente ainda não estava aberto.

Opened mudava a regra de passagem, mas não registrava um pacote. Não mostrava contador, compressão efetiva, reconstrução correta, rota ou resposta de aplicação.

A RFC 1144 explicou o ganho de reduzir cabeçalhos repetidos em linhas lentas. Negociar a possibilidade, comprimir um pacote, restaurá-lo e entregá-lo de forma útil continuam quatro eventos.

Administração protegida não completava a cadeia

A tabela de configuração foi separada para caber em outra MIB view. A RFC alertou para o risco do controle PPP e sugeriu somente leitura, views protegidas ou inacessibilidade. Os documentos vizinhos também separaram escopos: RFC 1471 para LCP e RFC 1472 para autenticação.

Uma trilha confiável liga autor da mudança, leitura do agente, geração, reinício, propostas por direção, respostas, transição Opened e observações de pacotes e aplicações.

Sem ela, preferência pendente parece ativa, leitura indefinida parece medição e estado parece entrega. A RFC 1473 tornou administrável justamente o espaço entre esses fatos.

Fontes