Resumo

  • Configure-Ack não podia aproveitar o “sim” para melhorar a proposta: Identifier, ordem e bytes das opções tinham de repetir exatamente o último Configure-Request.
  • A concordância LCP era bilateral. Nak oferecia valores aceitáveis, Reject encerrava a conversa sobre uma opção, e Opened exigia um Ack enviado e outro recebido.

A correção bem-intencionada invalidava o sim

Suponha que uma ponta informe o tamanho máximo de quadro que consegue receber. O vizinho entende Maximum-Receive-Unit, prefere um número próximo e o devolve em Configure-Ack. Para uma conversa humana, parece uma pequena concessão. Para o PPP, não é um aceite válido.

O RFC 1661 exige que o Ack use o Identifier do pedido mais recente e mantenha todas as opções na mesma ordem, sem qualquer modificação. Ele só cabe quando cada opção é conhecida e cada valor é aceitável. Quem responde pode concordar; não pode editar enquanto concorda.

A cópia literal resolve um problema de memória distribuída. Se o Ack pudesse trazer ajustes, o solicitante teria de descobrir se seu pedido foi aceito, substituído ou combinado com uma terceira configuração. Perda, retransmissão e pacotes cruzados ampliariam a dúvida. A igualdade dos bytes produz uma prova estreita: esta foi exatamente a proposta aceita.

O Identifier vincula a resposta à tentativa. Ele muda quando o conteúdo muda e depois de uma resposta válida ao pedido anterior; uma retransmissão pode reutilizá-lo. O campo não autentica a contraparte. Ele apenas impede que uma resposta velha governe uma proposta nova.

Sugerir e recusar eram atos diferentes

Configure-Nak atende à opção compreendida e negociável cujo valor não serve. O Nak remove da resposta o que já está aceitável, conserva os pontos de disputa e pode substituí-los por valores que seu emissor aceitaria. Também pode pedir uma opção obrigatória que faltou.

Essa sugestão não altera o pedido pendente. A origem escolhe se enviará outro Configure-Request; conteúdo novo recebe Identifier novo e volta a precisar de um Ack idêntico. A contraproposta só ganha efeito quando reaparece como proposta explícita.

Configure-Reject marca outro limite. A opção é desconhecida, não implementada ou retirada da negociação pela política local. A resposta copia a opção recusada, e o próximo pedido deve removê-la. Opções booleanas, sem valor alternativo, usam Reject em vez de Nak.

Os três códigos distribuem autoridade com precisão: Ack confirma, Nak indica um terreno possível, Reject nega esse terreno. Nenhum deles autoriza a outra máquina a reescrever uma exigência local.

Um enlace carregava duas negociações

Salvo regra específica, as opções LCP valem por sentido e normalmente descrevem a recepção de quem envia Configure-Request. A informa a B como A aceita receber; B envia outra lista sobre sua própria recepção.

Os pedidos podem se cruzar. A pode já ter recebido a confirmação de sua lista e ainda estar avaliando a de B. O RFC 1171 chamava esse momento de Ack-Received: houve concordância recebida, mas falta concordância enviada. Uma direção não toma emprestada a permissão da outra.

O RFC 1331 estabeleceu a condição de abertura: a fase termina quando Configure-Ack foi enviado e recebido. Portadora física ou um único Ack não permitem que uma ponta declare todo o enlace pronto.

Essa dupla evidência respeita assimetrias úteis. Capacidade de recepção, exigência de autenticação, compressão e tratamento de caracteres podem diferir. O PPP buscava compatibilidade entre máquinas diferentes, não a ficção de que eram iguais.

A omissão preservava o padrão

Configure-Request descreve alterações em relação aos padrões, não um inventário integral. RFC 1661 recomenda não enviar opções já no valor padrão. A ausência, portanto, também informa: continua valendo o default especificado.

Para reproduzir o estado efetivo, a operação deve combinar a lista aceita com os padrões e com o sentido de cada opção. Um log que armazena somente o que apareceu no pacote deixa parte da configuração invisível.

As opções de um pedido são avaliadas simultaneamente. Ack aceita a lista ordenada inteira; Nak relata apenas valores contestados; Reject carrega somente o que não participará. A resposta continua atômica sem obrigar nenhuma ponta a revelar todas as suas capacidades.

O idioma de controle sobrevivia à divergência

Algumas opções mudam o próprio formato do quadro. Se A começa a comprimir campos porque acredita que a negociação terminou, enquanto B ainda lê o formato padrão, até os pacotes de reparo podem ficar indecifráveis.

O RFC 1548 e o RFC 1661 preservam uma base: pacotes LCP de configuração, terminação e Code-Reject são enviados como se nenhuma opção estivesse ativa. A compressão dos campos Address, Control e Protocol não alcança esse conjunto.

Essa gramática não inventa concordância; mantém a discordância legível. Eficiência no plano de dados não pode cortar o caminho de volta ao controle comum.

Silêncio e barganha encontravam um fim

Configure-Request usa Restart timer porque o meio pode perder pacotes. Max-Configure limita tentativas sem resposta válida, deve ser configurável e tem dez transmissões como recomendação do RFC 1661.

Também existe conversa sem convergência. Max-Failure conta Naks consecutivos, com cinco como valor recomendado. Depois disso, novos Naks viram Rejects e a ponta deixa de acrescentar as opções que gostaria de exigir. O espaço de negociação encolhe em vez de ocupar o enlace para sempre.

Os contadores não provam ataque, falha física nem má-fé. Eles dão a cada participante uma razão local, mensurável, para abandonar uma tentativa sem evidência suficiente.

LCP aberto ainda não era IP pronto

Os quatro códigos aparecem no RFC 1134, de novembro de 1989, e atravessam RFC 1171, RFC 1331, RFC 1548 e a norma básica RFC 1661, de julho de 1994. A sequência de fases também ficou nítida.

Primeiro a camada inferior informa disponibilidade. LCP negocia o que independe da camada de rede. A autenticação, quando escolhida, vem depois. Em seguida, um Network Control Protocol abre separadamente cada protocolo de rede. Só o NCP correspondente autoriza seu tráfego.

Configure-Ack não prova identidade, autenticação concluída, endereço IP, rota ou aplicação. Ele prova apenas que a ponta respondeu favoravelmente a uma proposta LCP exata.

O registro PPP da IANA ainda conserva Request, Ack, Nak e Reject nos códigos 1 a 4, além do espaço de opções. A tabela coordena nomes e referências; não mede uso atual nem certifica implementações.

Concordância estreita tornou a diferença interoperável

O PPP recusou um “estamos de acordo” sem anatomia. Aceitar exigia cópia exata; sugerir e recusar tinham mensagens próprias; cada sentido guardava seu estado; silêncio e repetição tinham limites; camadas superiores precisavam conquistar outra abertura.

Nenhum coordenador central escolhia tamanho, compressão ou autenticação de cada enlace, e uma ponta não comandava a outra. A norma definiu fatos pequenos, observáveis pelas duas máquinas, e deixou a política com quem assumia o risco.

Fontes e limites

RFC 1134, RFC 1171, RFC 1331, RFC 1548 e RFC 1661 sustentam a evolução, a gramática, os estados e os limites. A IANA sustenta as atribuições atuais. Essas fontes não medem implantação contemporânea, conformidade de fornecedores, desempenho, práticas de operadoras ou um timeout universal. A leitura da cópia exata como autoridade bilateral mínima é uma inferência editorial.