Résumé

  • La liaison PPP devait d’abord atteindre sa phase de protocole réseau, puis IPv6CP devait arriver à l’état Opened; les échanges de contrôle portaient 0x8057, les datagrammes IPv6 admis 0x0057.
  • La différence entre les deux Interface-Token n’était garantie que dans la liaison concernée. Elle n’authentifiait aucun pair et ne prouvait ni adresse possédée, ni route, ni réception.

Le détail le plus instructif de la RFC 2023 est un Ack qui ressemblait à une proposition. Lorsqu’un pair demandait le jeton zéro et que l’autre extrémité disposait d’une valeur non nulle différente, le texte de 1996 prévoyait un Configure-Ack contenant une suggestion non nulle. La RFC 2472 corrigera ce cas en Configure-Nak. Elle rétablissait ainsi une distinction fondamentale : accepter la demande et proposer de la modifier ne produisent pas le même reçu.

Une ouverture en plusieurs étages

PPP n’assimilait pas la présence d’un support physique à une communication IPv6. Selon la RFC 1661, LCP devait établir, configurer et tester la liaison de données. Une authentification pouvait suivre. Ce n’est qu’ensuite que PPP atteignait la phase des protocoles réseau, où chaque protocole avait son NCP.

La RFC 2023 appelait celui d’IPv6 IPV6CP. Ses paquets utilisaient le champ protocole 8057 et ne devaient pas être échangés avant la phase réseau. Les paquets IPv6 utilisaient 0057; ils n’étaient admissibles qu’une fois IPv6CP Opened.

Cette chronologie interdit de fusionner les preuves. LCP Opened confirme un accord sur la liaison, pas la configuration d’IPv6. La phase réseau donne à IPv6CP le droit de négocier, pas la preuve qu’il a réussi. IPv6CP Opened autorise un type de trafic, sans montrer qu’un datagramme a quitté l’émetteur ou atteint sa destination.

Le test porte sur deux propositions locales

L’option Interface-Token avait le type 1, une longueur de six octets et une valeur de 32 bits. Chaque extrémité choisissait d’abord un jeton provisoire. Le document recommandait une valeur non nulle nourrie par plusieurs sources de différence; une adresse de liaison seule pouvait ne pas suffire. Faute d’une bonne source, zéro pouvait demander l’aide du pair.

Le récepteur comparait la valeur reçue à celle de sa dernière Configure-Request. Deux valeurs non nulles et différentes conduisaient à l’acceptation du jeton demandé. Deux valeurs égales et non nulles révélaient une collision et exigeaient un Configure-Nak avec une autre proposition. Deux zéros mettaient fin à la négociation automatique par Configure-Reject. Aucun jeton par défaut ne pouvait alors être inventé.

Les Nak croisés traitaient un cas plus fin. Si la suggestion reçue différait de la dernière suggestion envoyée, elle pouvait devenir la prochaine demande. Si les deux suggestions coïncidaient, il fallait choisir une nouvelle valeur provisoire. La convergence reposait sur la divergence probable de choix indépendants, pas sur une autorité mondiale.

Trois réponses, trois limites

Un Configure-Ack portant une valeur non nulle acceptée concerne une direction et une demande précises. Il ne termine pas magiquement l’autre direction. Surtout, il ne dit rien sur l’identité civile, organisationnelle ou cryptographique du pair. La section sécurité de la RFC 2023 ne traitait pas ces questions.

Un Configure-Nak signale une valeur refusée et en suggère une autre. Il ne prouve pas que le demandeur l’a reprise, qu’un Ack ultérieur l’a validée ou qu’IPv6CP s’est ouvert. Un Configure-Reject retire l’option : soit elle n’est pas mise en œuvre, soit les deux zéros ont rendu l’accord automatique impossible. Après ce rejet, la demande suivante doit omettre l’option. Le rejet n’est donc pas un mécanisme de secours réussi.

La révision de 1998 élargissait l’identifiant à 64 bits et transformait l’Ack modifié du cas zéro en Nak. La RFC 5072 a ensuite remplacé la RFC 2472. Le registre IANA actuel cite donc la RFC 5072 pour IPv6CP et conserve 004f comme ancienne valeur de compression. La RFC 2023 raconte une étape de conception, pas une consigne actuelle.

Une promesse de réception n’est pas un paquet

L’autre option d’IPv6CP négociait un protocole de compression IPv6. Elle exprimait une capacité de réception et devait être demandée séparément dans chaque direction. Par défaut, aucune compression n’était active. Une option acceptée ne prouve donc ni l’émission d’un paquet compressé, ni sa décompression, ni sa livraison.

La même discipline vaut pour les jetons. « Unique dans la liaison PPP » signifie que les deux extrémités doivent avoir des valeurs différentes dans cette négociation. Le résultat n’est pas une inscription dans un espace mondial. Il ne prouve ni un appareil permanent, ni un utilisateur, ni un droit d’usage. Il ne donne aucun titre sur l’adresse formée, aucune politique de routage et aucune disponibilité au-delà du pair.

Même voir une trame 0057 ne suffit pas. Cette observation établit qu’une trame contient un paquet classé IPv6 à cet endroit. La livraison exige d’autres traces : réception corrélée, contrôles d’intégrité, accusé de transport ou d’application, et continuité temporelle. La machine d’états ne peut produire ces preuves absentes.

La contribution durable de la RFC 2023 tient à cette modestie involontaire. Deux pairs pouvaient rendre visible une collision, refuser une proposition et recommencer jusqu’à obtenir deux valeurs différentes. Ils résolvaient une coordination locale. L’identité, l’autorité, la propriété, l’accessibilité et le résultat restaient des questions séparées.

Sources