Formateur de compression de zéros d'adresse IPv6 | Canonisation selon RFC 5952
Saisissez une adresse IPv6 et obtenez quatre formes côte à côte : la forme compressée canonique RFC 5952, la forme entièrement développée à huit groupes, une variante en majuscules et la forme mappée IPv4 pointée. Le nombre de séquences de zéros, la plus longue séquence et la longueur en caractères sont affichés pour comprendre pourquoi deux chaînes divergent.
💡 À propos de cet outil
La difficulté avec IPv6, c'est qu'une même adresse possède plusieurs écritures valides. 2001:db8::1 et 2001:0db8:0000:0000:0000:0000:0000:0001 désignent la même adresse, mais ce sont des chaînes différentes. En comparant une ACL de pare-feu à la configuration d'un routeur, ou en rapprochant un enregistrement PTR d'un journal d'accès, une différence d'écriture se lit comme une différence de valeur alors que les bits sont identiques.
RFC 5952 résout cela en définissant une représentation textuelle canonique unique : réduire à :: la plus longue séquence d'au moins deux groupes nuls, supprimer les zéros initiaux de chaque groupe et utiliser l'hexadécimal en minuscules. Cet outil applique ces règles de façon mécanique et affiche la forme canonique à côté de la forme développée (pratique pour le rapprochement de journaux et les enregistrements PTR) ainsi qu'une variante en majuscules pour comparer avec d'anciens équipements. Pour les adresses comprises dans ::ffff:0:0/96, il produit aussi la forme ::ffff:a.b.c.d ; hors de cette plage, le champ indique N/A. Il s'adresse à toute personne cherchant à uniformiser l'écriture IPv6 entre équipements, journaux et documentation.
🧐 Questions fréquentes
Q. Où placer exactement le :: ?
R. RFC 5952 réduit la plus longue séquence d'au moins deux groupes nuls consécutifs. En cas d'égalité de longueur, la séquence la plus à gauche l'emporte. Un seul groupe nul n'est jamais réduit en ::.
Q. Que se passe-t-il avec une adresse comportant deux séquences de zéros distinctes ?
R. Seule la plus longue est réduite. Par exemple, 2001:0:0:1:0:0:0:1 compresse les trois zéros finaux en 2001:0:0:1::1. La carte de détails indique le nombre de séquences et la plus longue pour confirmer le choix retenu.
Q. Pourquoi le champ mappé IPv4 affiche-t-il N/A ?
R. La notation ::ffff:a.b.c.d n'existe que pour les adresses de ::ffff:0:0/96 : 80 premiers bits à zéro, 16 bits suivants ffff. Toute autre adresse n'a pas d'équivalent IPv4, d'où le N/A.
Q. Les zéros initiaux sont-ils supprimés ?
R. Oui. Chaque groupe perd ses zéros initiaux : 0db8 devient db8 et 0042 devient 42. La forme développée fait l'inverse en complétant chaque groupe à quatre chiffres.
Q. Puis-je inclure un identifiant de zone comme %eth0 ?
R. Oui. L'identifiant de zone est exclu du calcul de compression et rajouté à la fin de chaque sortie tel que vous l'avez saisi.
Q. La sortie est-elle toujours une chaîne canonique unique ? R. Pour une adresse valide, oui : RFC 5952 a été rédigé pour que chaque adresse IPv6 ait exactement une représentation recommandée, à savoir la forme compressée affichée ici.
📚 Pourquoi un second RFC était nécessaire
RFC 4291 autorisait déjà le :: (utilisé une fois) et l'omission des zéros initiaux, mais il décrivait ce qui était autorisé, pas ce qui était canonique. Cela laissait 2001:db8:0:0:0:0:0:1 et 2001:db8::1 toutes deux valides, si bien que différentes piles réseau et personnes produisaient des chaînes distinctes pour une même adresse.
Cette ambiguïté rendait la corrélation de journaux et la comparaison d'adresses sujettes aux erreurs ; RFC 5952 a donc fixé une représentation recommandée : hexadécimal en minuscules, compression de la plus longue séquence de zéros et départage par la gauche. IPv4 n'a jamais connu ce problème — 192.0.2.1 s'écrit de la même façon par tout le monde — mais IPv6, avec ses adresses plus longues et ses abréviations facultatives, se disperse en variantes sans normalisation. Cette normalisation est précisément l'étape que gère ce formateur.