Expanseur et Compresseur IPv6
Développez n'importe quelle adresse IPv6 vers sa forme complète à 8 groupes ou compressez-la vers la forme canonique du RFC 5952, localement dans votre navigateur.
Chargement de Expanseur et Compresseur IPv6… Si rien ne se passe, activez JavaScript.
Une adresse IPv6 est un nombre de 128 bits, normalement écrit sous la forme de huit groupes de quatre chiffres hexadécimaux séparés par des deux-points, par exemple 2001:0db8:0000:0000:0000:0000:0000:0001. Comme cette forme complète est longue et pleine de zéros, IPv6 autorise deux règles abrégées : les zéros de tête au sein d'un groupe peuvent être supprimés, et une suite de groupes consécutifs entièrement à zéro peut être remplacée par un double deux-points. La même adresse peut donc s'écrire de façon compacte 2001:db8::1. Le problème est qu'une seule adresse possède de nombreuses représentations textuelles valides, ce qui rend les adresses difficiles à comparer à l'oeil, sujettes aux erreurs lors de la saisie dans des règles de pare-feu, et incohérentes entre les journaux et les fichiers de configuration.
Questions fréquentes
L'adresse que je saisis est-elle envoyée à un serveur ?
Quelle est la différence entre IPv6 développée et compressée ?
Qu'exige le RFC 5952 pour la forme canonique ?
Pourquoi :: ne peut-il apparaître qu'une seule fois dans une adresse ?
Puis-je coller une adresse avec des crochets ou un identifiant de zone ?
Gère-t-il les adresses mappées IPv4 comme ::ffff:192.168.0.1 ?
Qu'est-ce qui compte ici comme adresse IPv6 invalide ?
Pourquoi mon adresse revient-elle en minuscules ?
À propos de Expanseur et Compresseur IPv6
Cet outil convertit dans les deux sens. Donnez-lui n'importe quelle adresse IPv6 valide dans n'importe quelle notation et il produit la forme entièrement développée, les huit groupes complétés à quatre chiffres avec chaque zéro affiché, ainsi que la forme canonique compressée définie par le RFC 5952. La forme développée est idéale quand vous avez besoin d'une valeur sans ambiguïté pour une correspondance exacte de chaînes, pour scinder une adresse en ses moitiés réseau et interface, ou pour enseigner comment l'adresse est structurée. La forme compressée est la représentation correcte la plus courte et c'est celle que vous devriez stocker et afficher, car le RFC 5952 supprime l'ambiguïté en fixant exactement une orthographe canonique par adresse.
Toute l'analyse et la conversion se déroulent en TypeScript pur exécuté localement dans votre navigateur. Rien de ce que vous saisissez n'est téléversé, transmis ni journalisé, vous pouvez donc inspecter en toute sécurité des adresses internes, des préfixes et des identifiants d'hôte. L'analyseur valide son entrée et signale une erreur claire pour des problèmes tels que trop de groupes, plus d'un double deux-points, des valeurs hors plage ou des caractères invalides. Il comprend aussi quelques commodités du monde réel : les crochets entourant l'adresse tels qu'utilisés dans les URL, un identifiant de zone final comme %eth0, et un suffixe IPv4 intégré comme ::ffff:192.168.0.1, qu'il convertit en groupes hexadécimaux équivalents avant de développer ou de compresser.
Pourquoi une adresse avait tant d'orthographes
Lorsque IPv6 a été conçu, l'objectif était un vaste espace d'adresses de 128 bits, suffisant pour environ 340 sextillions d'adresses. Écrire un tel nombre en entier est peu commode, aussi les concepteurs ont-ils ajouté une abréviation : supprimer les zéros de tête dans chaque groupe, et réduire une suite de groupes à zéro en un double deux-points. Ces règles ont rendu les adresses bien plus lisibles, mais elles ont introduit un problème subtil. Une seule adresse pouvait désormais s'écrire de nombreuses façons toutes aussi valides, différant par l'emplacement du ::, par le fait que les zéros étaient complétés ou non, et par la casse des lettres.
Cette souplesse causait de réels casse-têtes opérationnels. Les journaux de deux systèmes pouvaient enregistrer le même hôte avec des orthographes différentes, des listes de contrôle d'accès pouvaient manquer une correspondance à cause d'une différence de casse, et une simple comparaison de chaînes ne permettait pas de savoir de façon fiable si deux adresses étaient identiques. Les ingénieurs réseau perdaient du temps à traquer des bogues qui n'étaient en réalité que deux orthographes d'une même adresse ne se comparant pas comme égales.
Le RFC 5952, publié en 2010, a corrigé cela en définissant une représentation canonique recommandée. Il a imposé l'hexadécimal en minuscules, l'absence de zéros de tête, le raccourcissement de la plus longue suite de zéros avec ::, le fait de ne jamais utiliser :: pour un seul groupe à zéro, et une règle de départage favorisant la suite la plus à gauche. Avec une orthographe officielle par adresse, les outils ont enfin pu normaliser et comparer les adresses IPv6 de manière fiable. Ce convertisseur implémente exactement cet algorithme, et c'est pourquoi sa sortie compressée peut servir sans risque de clé canonique.