Le plaisir de l’analyse des adresses IP

• Un article qui résume de façon claire et agréable ce qu’on apprend en construisant un parseur IPv4+v6 rapide

• Représentation canonique

→ v4 : 192.168.0.1 , un Dotted Quad de mots d’1 octet

→ v6 : 1:2:3:4:5:6:7:8 , un Colon-Hex de mots de 2 octets

[IPv6]

• Comme beaucoup de zéros peuvent apparaître au milieu, :: permet de supprimer une ou plusieurs séquences de 0

→ 1:2::3:4 = 1:2:0:0:0:0:3:4

• Les 32 derniers bits peuvent être écrits avec la notation Dotted Quad de v4

→ 1:2:3:4:5:6:77.77.88.88 = 1:2:3:4:5:6:4d4d:5858

→ fe80::1.2.3.4 = fe80:0:0:0:0:0:102:304

• Cela devient un peu plus complexe quand :: apparaît au début ou à la fin

→ ::1 = 0:0:0:0:0:0:0:1

→ 1:: = 1:0:0:0:0:0:0:0

→ :: = 0:0:0:0:0:0:0:0

• Tous les champs d’un IPv6 en Colon-Hex sont des nombres hexadécimaux sur 4 chiffres, avec possibilité d’omettre les zéros initiaux

→ :: = 0000:0000:0000:0000:0000:0000:0000:0000

[IPv4]

• Ce qui est amusant, c’est qu’avant l’officialisation de la notation Dotted Quad pour les 32 derniers bits en IPv6, elle n’avait jamais été standardisée dans aucun document

→ Du coup, le standard de fait dans l’industrie était souvent : « est-ce que 4.2BSD sait l’interpréter ? » et « qu’est-ce que les autres OS ont conservé en copiant 4.2BSD ? »

• Mais 4.2BSD est un peu étrange (whacky)

→ 192.168.140.255 = 3232271615

→ Autrement dit, si on visite http://3232271615 dans Chrome, il charge http://192.168.140.255. Après tout, c’est un nombre sur 4 octets !

→ La forme octale http://0300.0250.0214.0377 fonctionne aussi

→ Donc bien sûr, la forme hexadécimale https://0xc0.0xa8.0x8c.0xff correspond elle aussi à la même adresse

• Le CIDR (Classless Inter-Domain Routing) a aussi un impact sur les adresses IP

→ La notation de classe C 192.168.140.255 peut s’écrire en classe B comme http://192.168.36095, ou en classe A comme http://192.11046143

→ C’est pour cela que ping 127.1 équivaut à 127.0.0.1. Ce n’est pas une suppression de zéros consécutifs comme en IPv6, cela signifie le 1er hôte du réseau de classe A 127. Autrement dit, le nombre 24 bits 1

• Combien de zéros initiaux peut-on mettre devant chaque quad ?

→ 001.002.003.004 ? 0000000001.0000000002.0000000003.000000004 ?

→ ( Chrome accepte aussi http://0000000001.0000000002.0000000003.000000004 )

→ Dans ce cas, faut-il lire ces nombres en octal ou en hexadécimal ? Les implémentations récentes ont abandonné l’octal et l’hexadécimal, et traitent les zéros initiaux comme du décimal

• Ce problème des zéros initiaux affecte aussi IPv6

→ 000001::00001.00002.00003.00004 = 1::1.2.3.4, or 1::102:304

→ Comme la plupart des parseurs récents utilisent une bibliothèque de type « parse integer », ils acceptent généralement n’importe quel nombre de zéros initiaux

En d’autres termes, pour parser toutes les adresses IP, il faut tenir compte de toutes ces bizarreries pénibles…

L’auteur du parseur a donc choisi de ne prendre en charge que ceci :

• Le style v4 classique avec des entiers séparés par des points, avec un nombre illimité de zéros initiaux

• Pas de prise en charge des notations de classe A/B ni de l’octal/hexadécimal

• Pas de prise en charge non plus de la représentation complète sous la forme d’un seul entier uint32

• Pour IPv6, prise en charge de la forme canonique colon-hex, de l’abréviation ::, ainsi que de l’ajout d’un IPv4 sur les 32 derniers bits (cet IPv4 suit les règles ci-dessus). Le nombre de zéros initiaux est illimité dans chaque champ

• Au départ, la possibilité d’ajouter une adresse IPv4 à la fin avait été incluse pour faciliter la transition d’IPv4 vers IPv6, mais en pratique on la voit rarement. C’est donc pris en charge, sans être jugé particulièrement utile.

[minhoryang]

Oh, c’est sympa ! On voit beaucoup de techniques bien utiles pour contourner des protections lors d’une attaque !

[galadbran]

Franchement, je me dis que s’il faut utiliser des règles aussi compliquées juste pour noter une adresse IP, ce n’est pas un gaspillage inutile de ressources informatiques ? ^^;;