3.2. Analyse et modification

3.2. Analyse et modification (Parsing and Modifying)

3.2.1. Vue générale

Avec toutes les méthodes possibles de représentation textuelle, chaque application doit inclure un module, un objet ou une fonction qui analyse les adresses IPv6 de manière à ce que, quel que soit le format, elles soient interprétées comme la même adresse. De nombreux ingénieurs systèmes intégrant des plateformes complexes pour des clients d'entreprise auront du mal à constater que leur outil favori ne dispose pas de cette fonction, ou rencontreront des difficultés telles que la nécessité de réécrire leurs macros ou scripts pour leurs clients.

3.2.2. Journalisation

Si une application produit un récapitulatif de journal représentant l'adresse en intégralité (par exemple 2001:0db8:0000:0000:1111:2222:3333:4444), la sortie sera très peu lisible comparée à celle d'IPv4. L'adresse devra être analysée et reformatée pour être utile à un lecteur humain. Pour les systèmes critiques, la journalisation se fait parfois par mise en miroir du même trafic vers deux systèmes différents. Il faut veiller à ce que, quelle que soit la sortie, les journaux soient analysés de manière à être équivalents.

3.2.3. Audit : cas 1

Quand on audite la configuration d'un routeur ou de tout autre équipement réseau, il existe de nombreuses méthodes pour comparer les informations de configuration d'un nœud. Parfois, l'audit consiste simplement à comparer les changements quotidiens. Si la configuration passe de 2001:db8::1 à 2001:0db8:0000:0000:0000:0000:0000:0001 simplement parce qu'un nouvel ingénieur a estimé que c'était mieux, un simple diff montrera qu'une adresse différente a été configurée. Sur un réseau de grande envergure, on perdra alors du temps à se demander « pourquoi ces zéros supplémentaires » au lieu de mener l'audit. De nombreux outils sont de simples diffs qui ne tiennent pas compte des règles de représentation des adresses.

3.2.4. Audit : cas 2

La configuration des nœuds sera comparée à un système d'information qui gère les adresses IP. Si la notation diverge, il faudra implémenter un script pour la prendre en compte. Le résultat d'une opération SNMP GET, converti en texte et comparé à une adresse textuelle saisie par un humain, a peu de chances de correspondre du premier coup.

3.2.5. Vérification

Certains protocoles imposent la vérification de certains champs de données. Les certificats X.509 en sont un exemple. Si un champ d'adresse IPv6 dans un certificat est vérifié de manière incorrecte par conversion en texte puis comparaison textuelle simple à une autre adresse, le certificat peut être considéré à tort comme invalide en raison d'une différence de représentation textuelle.

3.2.6. Modification inattendue

Parfois, un système prend une adresse et la modifie par commodité. Par exemple, il peut prendre l'entrée 2001:0db8:0::1 et produire la sortie 2001:db8::1. Si les zéros avaient été saisis pour une raison précise, le résultat peut être quelque peu inattendu.