Licence CC BY

17.2 ?

Une date ou une IP ?

Hey \o,

Comme le fait très bien remarquer @Vince sur sur le sujet béta de son tutoriel Les réseaux de zéro.

17.02.2022 n’est pas une adresse IP valide.

Mais saviez-vous que 17.02, si ? Enfin presque, il me semble que ça n’ait jamais été normalisé, bien que compris par la plupart des logiciels. Intéressant n’est-ce pas ? Vous devriez peut-être le noter.

Oui, non peut-être pas en fait. 🤔
Ah si ! J’ai bien un cas d’utilisation.

Si jamais vous avez besoin de faire un ping rapide, généralement, vous pingez un serveur DNS. Par exemple Google au 8.8.8.8 (secondaire 8.8.4.4) ou Cloudflare 1.1.1.1 (secondaire 1.0.0.1). Contrairement à Google, Cloudflare a bien choisi son serveur DNS secondaire, si bien que souvent c’est lui qu’on préfère pinger, on y gagne 4 caractères !

$ ping 1.1

Il existe plein de formats d’IPv4 bizarres, je pense peut-être dû à l’absence de normalisation. En tout cas, l’adresse IP du serveur DNS secondaire de Cloudflare vaut de l’or. Il n’existe aucune adresse IP plus courte.

Je sais pas pourquoi je vous parle de ça moi. 🙄

À bientôt les agrumes ! \o



13 commentaires

Si jamais vous avez besoin de faire un ping rapide, généralement, vous pingez un serveur DNS. Par exemple Google au 8.8.8.8 (secondaire 8.8.4.4) ou Cloudflare 1.1.1.1 (secondaire 1.0.0.1). Contrairement à Google, Cloudflare a bien choisi son serveur DNS secondaire, si bien que souvent c’est lui qu’on préfère pinger, on y gagne 4 caractères !

L’adresse 1.0.0.1/1.1 a aussi le bon goût d’être anycastée dans la plupart des régions du monde (comme celles de Google d’ailleurs), ce qui lui confère en principe une faible latence où que l’on soit, pour faire son ping. ^^

+2 -0

C’est de la sorcellerie mathématiques ces adresses IP en fait

Fondamentalement, une adresse IP v4 est juste un entier non-signé sur 32 bits. On les écrit souvent sous forme de 4 chiffres en base 256, eux même écrit en base 10 et séparé par des points. Mais c’est qu’un choix parmi d’autres. C’est pas plus magique que d’écrire un code RGBA (aussi un entier 32 bits) comme 4 chiffres en base 256, eux même écrits comme une paire de chiffres en base hexa la plupart du temps.

+1 -0

Ça explique pourquoi 01002004010 et 134744072 fonctionnent mais pour 1.1. Il y a la transformation 1.0.0.1 qui n’aide pas du tout à la compréhension.

+0 -0

C’est surtout que 1.1 mixe deux écritures et par convention le premier 1 est lu comme si c’était le premier chiffre en base 256 d’une IP bien écrite (i.e. l’octet le plus fort d’un nombre de 32 bits), et le deuxième 1 est lu comme une écriture décimale du reste du nombre. Donc t’as effectivement la valeur 1 << 24 + 1. C’est une convention un peu bizarre (sans doute choisie parce que c’est la plus pratique étant donnée la façon dont sont attribuées les IP), mais il y a rien de sorcier. Au final, a.b.c.d est juste a << 24 + b << 16 + c << 8 + d et par convention si il manque des chiffres dans l’écriture on les attribue aux positions les plus fortes d’abord et le dernier est attribué à d.

EDIT : ce qui rend le truc un peu incohérent, c’est par exemple que 8.8.0.2056 est rejetée alors que 8.8.2056 est acceptée.

+3 -0

D’après les RFCs, 010.010.010.010 est identique à 8.8.8.8 et 10.257 est parfaitement valide…
Outre l’octal, on peut utiliser l’hexa, et dans les trois cas la forme pointée ou l’entier unique… Tout cela étant reconnu par inet_addr() POSIX Appliqué à la loopback, on 127.0.0.1 = 0177.0.0.1 = 0x7f.0.0.1 = 127.0.1 = 127.1 = 2130706433 = 017700000001 = 0x7f000001

Y a déjà assez de quoi donner la migraine pour ne pas rajouter les gens qui jouent à cache-cache : obfuscation IPvWalmart

Je suis désolé, ça fait une vingtaine de RFCs que je parcours à commencer par la RFC 790 et 010.020.000.052 se réfère à 10.20.0.52 et pas à 8.16.0.42.

Donc dire d’après les RFCs c’est bien mais lesquelles ? Pour moi, c’est POSIX qui fait du zèle et se base sur le standard C pour ces notations, je me base sur la norme POSIX que tu as cité pour affirmer ça. Absolument pas de RFC associée selon moi, d’où le fait que je parle d’absence de normalisation.

Après, ici, ce billet avait pour but de glisser des indices sur la sortie du livre de @Vince le 17 février de cette année. Donc il se voulait un peu léger.

+0 -0

Je suis désolé, ça fait une vingtaine de RFCs que je parcours à commencer par la RFC 790 et 010.020.000.052 se réfère à 10.20.0.52 et pas à 8.16.0.42.

Il y a quelques jours, j’ai eu un étudiant qui écrivait les adresses IP avec les zéros inutiles (donc 010.020…). J’ai ouvert des yeux ronds mais bon, ça fonctionnait. Sur quel système c’était, par contre, je ne me souviens plus.

Donc dire d’après les RFCs c’est bien mais lesquelles ? Pour moi, c’est POSIX qui fait du zèle et se base sur le standard C pour ces notations, je me base sur la norme POSIX que tu as cité pour affirmer ça. Absolument pas de RFC associée selon moi, d’où le fait que je parle d’absence de normalisation.

Oui, pardon, je voulais dire que les RFCs ne sont pas précises sur l’interprétation mais acceptent la notation avec les zéros préfixant. On est d’accord que c’est pas (bien) normalisé…! POSIX ne fait pas de zèle, à mon sens, mais reste plutôt cohérent avec l’existant et son héritage C/Unix.

Ceci dit, seule la forme décimale a été retenue dans les nouvelles fonctions POSIX inet_ntop() et inet_pton() qui gèrent IPv4 et IPv6 avec la compression de zéros (i.e. 2001:0db8:85a3:0000:0000:8a2e:9370:7334 = 2001:db8:85a3::8a2e:9370:7334.)

Il y a quelques jours, j’ai eu un étudiant qui écrivait les adresses IP avec les zéros inutiles (donc 010.020…). J’ai ouvert des yeux ronds mais bon, ça fonctionnait. Sur quel système c’était, par contre, je ne me souviens plus.

Je mettais aussi des zéro au début, sur papier, parce-que ça aide visuellement pour faire des conversions mentalement. Sur machine, ça fonctionne sur certains systèmes (notamment les Fenêtres) mais pas sur d’autres (pratiquement tout ce qui est fortement POSIX-compliant comme les BSD et les GNU/Linux.) L’interprétation des zéros initiaux dépend hélas des implémentations et des époques.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte