Résumé

  • L’état Opened d’IPV6CP autorise l’étape IPv6 de la liaison PPP ; il ne prouve ni la formation d’une adresse globale utilisable ni l’existence d’un chemin de bout en bout.
  • Supprimer le DAD d’une adresse globale revient à miser sur deux invariants de topologie précis, qu’il faut démontrer et surveiller séparément.

Pendant une intervention sur un routeur d’accès, le journal indique un Configure-Ack puis Opened. L’équipe voit deux identifiants distincts et classe l’abonné parmi les accès IPv6 opérationnels.

La trace n’est pas fausse. La conclusion est trop large.

RFC 5072 organise le passage d’une liaison PPP vers IPv6. PPP doit atteindre la phase protocole réseau, puis IPV6CP doit atteindre son état ouvert avant qu’un paquet IPv6 puisse être communiqué. Ces conditions empêchent d’envoyer le trafic trop tôt. Elles ne fabriquent pas, à elles seules, une adresse globale, une route ou une réponse distante.

Le mécanisme négocié reste local. L’option Interface-Identifier transporte 64 bits. Chaque requête en contient exactement une. Deux valeurs non nulles et différentes peuvent être acquittées ; une égalité appelle un Nak et une nouvelle proposition ; deux valeurs nulles conduisent au rejet. Ce dialogue vise l’unicité sur cette liaison point à point, pas dans tout un domaine d’adressage.

Le cas d’échec mérite autant d’attention que le chemin heureux. Si aucun identifiant valable n’est négocié, le texte interdit de supposer une valeur par défaut. La reprise n’est pas spécifiée ; une configuration manuelle n’est qu’une possibilité. Une plate-forme peut automatiser cette reprise, mais elle doit alors en conserver la décision comme un acte distinct de la norme.

L’adresse lien-local utilise l’identifiant négocié. Pour l’adresse globale, le RFC formule une mise en garde explicite : il ne faut pas supposer que le même identifiant sera repris. Le pair peut en produire plusieurs autres. Dès lors, un collecteur limité à IPV6CP ne sait pas quelle adresse globale a réellement été construite.

Cette séparation explique le traitement différent du DAD. Pour l’adresse lien-local issue de la négociation, rechercher un doublon est redondant : les deux extrémités ont déjà distingué leurs valeurs sur la liaison. Pour les adresses globales, l’exception ne tient que si deux conditions sont vraies simultanément.

Première condition : le préfixe annoncé par le routeur d’accès est réservé exclusivement à cette liaison PPP. Deuxième condition : ce routeur ne s’attribue pas lui-même une adresse globale construite dans ce préfixe. Si les deux sont prouvées, RFC 5072 recommande à l’administration système de mettre DupAddrDetectTransmits à zéro.

Ce zéro ne signifie pas « test réussi ». Il signifie « test non exécuté parce qu’une architecture contrôlée tient lieu de garantie ». La preuve se déplace donc vers l’inventaire des préfixes, la configuration du routeur et la maîtrise des changements. Une réutilisation de préfixe ou une nouvelle adresse sur le routeur invalide la prémisse sans modifier l’ancien acquittement IPV6CP.

RFC 4862 fournit la règle générale : les adresses unicast doivent subir le DAD avant leur attribution, qu’elles proviennent de SLAAC, de DHCPv6 ou d’une saisie manuelle, sauf exceptions énoncées. Il précise qu’une valeur zéro désactive le DAD. Le contrôle compensatoire doit donc être nommé, pas imaginé.

L’origine de l’adresse globale compte aussi. L’annexe de RFC 5072 sépare la voie sans état, où un préfixe d’annonce de routeur est combiné à un identifiant, de la voie avec état, où un serveur tel que DHCPv6 délivre l’adresse. Une annonce de préfixe, un bail, une adresse installée et une route sont quatre reçus différents.

La politique d’identifiant a ensuite évolué. RFC 8064 met formellement RFC 5072 à jour, recommande la méthode opaque de RFC 7217 pour les adresses SLAAC stables et déconseille d’incorporer une adresse stable de couche liaison. Une politique normative de 2017 ne décrit cependant pas automatiquement le code qui tourne sur un équipement donné.

Enfin, l’ouverture d’IPV6CP ne remplace ni admission, ni authentification, ni chiffrement. RFC 5072 les cite comme protections distinctes et rappelle qu’une méthode fondée sur MD5 peut être rejouée. La réussite du contrôle IPv6 peut coexister avec une assurance d’identité insuffisante.

Le dossier d’activation devrait donc relier, sans les fusionner : état LCP ; authentification et autorisation ; transcript IPV6CP ; identifiants local et distant ; adresse lien-local ; méthode de création globale ; préfixe et durées ; DAD réalisé ou preuve des deux conditions d’exception ; adresse et route installées ; paquet sortant ; réponse du pair ; résultat applicatif.

Cette chaîne est une recommandation d’exploitation. Elle reprend la discipline des couches de réalité de Heng Lu : une intention de configuration, un état de protocole, un état d’adresse, un fait de transmission et un résultat métier ne deviennent pas équivalents parce qu’ils apparaissent sur le même écran.

Sources