17.2 ?

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.

17.02.2022 n’est pas une adresse IP valide.

ping 17.02.2022 marchera, 2022 étant 7*256 + 230, ca nous donne 17.2.7.230 comme ipv4, ce qui est valide pour la commande ping

ping 17.02.2022
PING 17.02.2022 (17.2.7.230) 56(84) bytes of data.

Pour info,

134744072 est également une IP valide (sous la forme d’un integer). Faites le test si vous ne me croyez pas

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

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.

Ç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.

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.

J-25

Hey hey !
Ça y est @Vince l’a annoncé !

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 :

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.

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.