Resumo

  • Com LCP em Opened, o recebimento de um valor desconhecido no campo PPP Protocol exigia uma resposta Protocol-Reject de código 8, não o encerramento automático do enlace.
  • A resposta identificava o protocolo em dois octetos e devolvia informação do pacote sem cabeçalhos de enlace ou FCS, truncada para caber na MRU estabelecida pelo par.
  • O rejeite de um NCP podia ser RXJ+, parte de uma operação tolerável; o rejeite do próprio LCP era RXJ-, pois destruía a linguagem comum que sustentava o enlace.

O enlace comum e seus ocupantes tinham estados diferentes

O RFC 1134, de 1989, apresentou PPP como um modo de transportar datagramas de vários protocolos de rede em enlaces ponto a ponto. LCP cuidava do enlace comum. Uma família de Network Control Protocols configurava cada protocolo de camada de rede. Essa arquitetura permitia coexistência, mas não obrigava os dois lados a conhecer o mesmo catálogo inteiro.

O caso interessante surgia depois que o enlace já estava aberto. Um par recebia um pacote cujo campo Protocol não reconhecia. Se a máquina LCP estivesse no estado Open, a norma exigia um pacote LCP com Code 8, Protocol-Reject. O mecanismo recusava uma carga tipada sem transformar imediatamente a discordância em evidência de que o meio ou todo o PPP havia falhado.

Em 1992, o RFC 1331 separou duas causas. Um protocolo conhecido, recebido antes de seu NCP chegar a Opened, deveria ser descartado silenciosamente. Um campo Protocol desconhecido deveria ser rejeitado quando LCP estivesse Opened. A primeira situação falava de fase; a segunda, de capacidade.

Por isso o silêncio não confirma suporte. LCP pode estar em outro estado, o NCP pode não ter aberto, uma resposta pode se perder ou a implementação pode desobedecer à norma. E a presença de Code 8 tampouco prova rompimento físico, falha de autenticação ou indisponibilidade de todos os protocolos. Ela aponta uma incompatibilidade localizada.

A devolução do erro também obedecia à MRU

No RFC 1661, Code vale 8 e Identifier precisa mudar a cada Protocol-Reject enviado. Rejected-Protocol tem dois octetos e contém o campo PPP Protocol do pacote recusado.

Rejected-Information começa no campo Information daquele pacote. Não leva cabeçalhos de enlace nem FCS e precisa ser truncado para respeitar a Maximum-Receive-Unit estabelecida pelo par. A mensagem inclui contexto suficiente para reconhecer o estímulo, mas não ganha licença para ultrapassar o contrato de recepção só porque relata um erro.

Essa informação não é uma cópia integral do quadro. Pode terminar cedo e exclui partes específicas. Identifier também não é um número global de incidente. O valor probatório é mais estreito: liga uma declaração de não suporte a um campo de protocolo e a uma porção limitada do pacote que a provocou.

O limite também evita que o caminho de erro amplifique o estímulo. Uma implementação não pode devolver informação sem medida só porque deseja explicar uma incompatibilidade; a resposta continua subordinada ao tamanho que o outro lado aceitou. Rejected-Protocol preserva a atribuição mínima quando a cópia precisa ser curta. MRU responde quanto pode voltar; o campo de dois octetos responde o que, no mínimo, precisa ser nomeado.

O RFC 1548 manteve o desenho em 1993, e o RFC 1661 o consolidou em 1994. A continuidade normativa mostra estabilidade do mecanismo, não conformidade universal dos produtos.

A obrigação de parar ficava no remetente

Ao receber Protocol-Reject, a implementação tinha de cessar o envio do protocolo indicado na primeira oportunidade. A expressão admite pacotes já enfileirados ou em trânsito. Não permite continuar indefinidamente como se o rejeite fosse apenas perda transitória.

O RFC 1332 define IPCP, que estabelece e configura IP sobre PPP. O RFC 5072 define IPv6CP. Eles ilustram como NCPs distintos ocupam o mesmo enlace; não provam que uma rede ou equipamento específico os utiliza. Se um NCP for recusado, seu serviço de rede não se torna disponível só porque LCP continua ativo. Qualquer outro protocolo depende do próprio suporte e da própria configuração.

Protocol-Reject só pode ser enviado em LCP Opened. Se recebido fora desse estado, deve ser descartado silenciosamente. A regra vincula autoridade a contexto: uma recusa só pode dirigir o outro lado depois de ambos concordarem com o plano de controle que transporta a recusa.

O objeto rejeitado mudava a classe do evento

O RFC 1331 chamou de RXJ+ uma rejeição permitida. Protocol-Reject de um NCP era o exemplo: uma condição dentro do escopo da operação normal. O remetente parava aquele tipo de pacote, enquanto LCP podia continuar aberto.

RXJ- era catastrófico. Protocol-Reject de LCP representava erro irrecuperável e encerrava a conexão. O formato era o mesmo, porém a fundação negada era outra. Um NCP pode falhar e ainda ser descrito por LCP. Se LCP é o protocolo que o par declara não conhecer, desaparece a linguagem compartilhada para configurar, testar e limitar o desacordo.

Preservar o enlace, portanto, não equivale a preservar utilidade. Uma aplicação que depende do único NCP recusado pode sofrer indisponibilidade total mesmo com LCP Opened. Disponibilidade do portador e disponibilidade do serviço precisam de métricas separadas.

O registro atribuía números, não instalava suporte

O registro da IANA para números PPP lista o Code 8 de LCP como Protocol-Reject e publica as atribuições do campo Protocol. Ele é fonte para decodificar um valor, mas não demonstra implementação, estado Opened, tráfego atual nem sucesso de negociação.

O RFC 3818 revisou a política de alocação dos espaços PPP para um processo de consenso IETF. Isso evidencia governança de uma extensão, não adoção. Uma alegação operacional precisa juntar registro, configuração, estados, captura e comportamento após a recusa.

Também convém não misturar rejeições diferentes. Configure-Reject recusa uma opção de configuração LCP durante a negociação; Code-Reject informa um código LCP desconhecido; Protocol-Reject aponta o campo PPP Protocol. Um painel que soma todos sob a palavra “rejeite” apaga justamente o tipo que determina se a reação correta é renegociar, interromper um protocolo ou encerrar o enlace.

Fontes