Resumo

  • O IPv6 só podia atravessar o enlace depois da fase de protocolos de rede do PPP e do estado Opened do IPv6CP; 0x8057 identificava controle, e 0x0057, dados IPv6.
  • Valores distintos de Interface-Token comprovavam diferença entre as duas pontas daquela negociação. Não autenticavam o par nem comprovavam unicidade global, posse do endereço, alcance de rota ou entrega.

Um caso da RFC 2023 mostra por que o nome da resposta importa. Quando um par solicitava token zero e a outra ponta tinha valor não zero diferente, o texto mandava devolver uma sugestão não zero em Configure-Ack. A RFC 2472 mudou a resposta para Configure-Nak. Aceitar o pedido e propor outro valor passaram a produzir recibos coerentes com ações diferentes.

O enlace de dados era apenas o primeiro portão

Na arquitetura da RFC 1661, LCP estabelecia, configurava e testava a conexão de enlace. Podia haver autenticação. Só depois o PPP chegava à fase de protocolos de rede, em que cada protocolo era configurado por seu NCP.

A RFC 2023 chamou o NCP do IPv6 de IPv6CP. Pacotes de controle usavam o valor PPP 8057 e não podiam circular antes da fase de rede. Datagramas IPv6 usavam 0057 e aguardavam o IPv6CP atingir Opened.

LCP Opened, portanto, não significava IPv6 pronto. A fase de rede permitia a negociação, mas não a concluía. IPv6CP Opened liberava uma classe de pacotes, sem criar rota, transmitir um datagrama ou obter confirmação da aplicação.

A unicidade era uma comparação entre duas pontas

A opção Interface-Token, tipo 1 e comprimento 6, carregava 32 bits. Cada implementação escolhia um candidato antes de enviar Configure-Request. A recomendação era usar várias fontes de diferença para produzir valor não zero; um endereço de enlace isolado poderia não bastar. Sem fonte adequada, zero permitia pedir que o par sugerisse um valor.

O receptor comparava o pedido remoto com seu pedido local mais recente. Valores diferentes e não zero podiam ser reconhecidos. Valores iguais e não zero revelavam colisão e exigiam Configure-Nak com outra sugestão. Dois zeros encerravam a negociação automática com Configure-Reject, sem valor padrão e sem recuperação definida.

Se as duas pontas cruzassem a mesma sugestão em Naks, uma delas deveria escolher novo candidato. Se a sugestão recebida diferisse da última sugestão enviada ao par, poderia entrar no próximo Configure-Request. A convergência vinha da exposição da colisão e de novas rodadas, não de um cadastro mundial.

Ack, Nak e Reject não diziam a mesma coisa

Configure-Ack de token não zero aceitava uma solicitação específica em uma direção. Não completava a direção oposta e não identificava o par. A própria RFC 2023 não discutiu segurança; o token não era credencial.

Configure-Nak registrava discordância e oferecia alternativa. Não provava que ela foi solicitada depois, reconhecida ou instalada. Configure-Reject retirava a opção de pedidos futuros. Poderia representar falta de implementação ou o impasse zero contra zero; não demonstrava que uma configuração manual resolveu o caso.

O escopo escrito na RFC era “dentro do enlace PPP”. A diferença separava as duas pontas daquela sessão, mas não atribuía um nome global, permanente ou juridicamente controlado. Não dizia quem era o usuário, qual organização autorizou o acesso ou quem possuía o endereço formado.

Capacidade negociada não era uso comprovado

A segunda opção do IPv6CP negociava um protocolo de compressão IPv6. Ela declarava capacidade de receber; cada direção precisava solicitá-la separadamente e o padrão era sem compressão. A aceitação da opção não provava que houve pacote comprimido, descompressão bem-sucedida ou entrega.

A RFC 2472 substituiu o token de 32 bits por um Interface-Identifier de 64 bits e corrigiu o tratamento do zero. A RFC 5072 substituiu depois a RFC 2472. O registro IANA atual preserva 0057 e 8057, mas aponta IPv6CP para a RFC 5072; 004f aparece como valor histórico. A RFC 2023 é, assim, evidência de uma etapa do projeto.

Até uma captura de 0057 tem alcance limitado. Ela mostra, no ponto observado, um quadro classificado como portador de um pacote IPv6. Entrega exige observação correlacionada no destino, integridade e resposta de transporte ou aplicação. Identidade e autorização exigem credenciais e decisões de acesso.

A lição permanece útil: um protocolo distribuído pode resolver um conflito local sem prometer verdade universal. IPv6CP fazia a colisão aparecer, negava o valor e tentava de novo até separar as pontas. Tudo além dessa separação precisava de outro dono e de outra prova.

Fontes