Veille
Derniers articles
Dernières analyses sur les opérateurs d'infrastructure, les décisions politiques, les mouvements de marché et les évolutions du pouvoir numérique.

Dossier
Le paquet n’avait pas de SRH. Il pouvait tout de même viser un SID SRv6
Le pare-feu frontal cherche un en-tête de routage de type 4, n’en trouve pas et classe le paquet comme IPv6 ordinaire. L’adresse de destination correspond pourtant à une fonction SRv6 locale. L’équipement a bien lu le paquet; c’est la question posée qui était trop étroite.

Histoire d'Internet
Le MX a trouvé une passerelle. Il n’a pas prouvé que le télécopieur existait : RFC 1486
Pour faire entrer un numéro de téléphone dans le DNS, l’expérience de 1993 commençait par le lire à l’envers. Cette inversion rendait la délégation possible; elle ne transformait ni le DNS en annuaire téléphonique, ni une route de courrier en preuve de remise sur papier.

Dossier
RFC 9814 : le vérificateur a reçu le flux avant de savoir exactement ce qui serait signé
Dans un service de vérification en continu, le contenu peut arriver bien avant le certificat, les attributs et la signature. Le système calcule alors un condensat au fil de l’eau, libère les blocs déjà traités, puis découvre à la fin la petite structure que SLH-DSA doit vérifier.…

Histoire d'Internet
La chaîne portait le nom distinctif. Elle ne devenait pas l’entrée d’annuaire : RFC 1485
Le résumé de veille La chaîne portait le nom distinctif. Elle ne devenait pas l’entrée d’annuaire: RFC 1485 explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles pour…

Dossier
Derrière une même adresse NAT, l’identité PSK choisit désormais le client RADIUS : RFC 9813
Deux contrôleurs d’accès appartenant à des équipes différentes peuvent sortir par la même adresse publique. Pour le serveur RADIUS, leur provenance réseau est identique, mais leurs droits et leurs secrets ne devraient pas l’être. RFC 9813 introduit l’identité PSK comme clé de…

Histoire d'Internet
La chaîne se laissait analyser sans ambiguïté. Elle n’était toujours pas l’entrée d’annuaire : RFC 1485
Deux logiciels pouvaient imprimer différemment le même nom X.500, puis reconstruire la même suite structurée de composants. RFC 1485 rendait ce passage vérifiable; il ne transformait ni la typographie en forme canonique, ni le nom obtenu en preuve d’existence ou d’autorité.

Dossier
La requête HTTP a répondu 200. La décision sur le certificat restait à l’intérieur : RFC 9811
Une supervision peut voir une requête verte alors que l’autorité de certification a refusé l’opération, l’a modifiée ou attend encore une approbation. La RFC 9811 ne présente pas ce décalage comme une anomalie: elle construit précisément la frontière entre la remise HTTP et la…

Histoire d'Internet
Le nom tenait sur une carte de visite. L’identité dépendait encore de l’annuaire qui l’entourait : RFC 1484
Une carte pouvait porter « S. Hardcastle-Kille, ISODE Consortium, GB » au lieu d’un chemin X.500 entièrement typé. Cette élégance n’effaçait pas le chemin: elle demandait à l’annuaire, au logiciel local et parfois au lecteur de le reconstruire.

Histoire d'Internet
Le protocole n’était pas toujours écrit dans le PDU : RFC 1483 et le sens caché dans le circuit
Une seule connexion virtuelle pouvait porter plusieurs protocoles, à condition que chaque PDU annonce sa nature. Ou bien chaque protocole pouvait obtenir sa propre connexion et se passer de cette annonce. RFC 1483 ne supprimait pas l’information: il choisissait entre le coût d’un…

Histoire d'Internet
Le soutien de l’IAB ne déployait pas CIDR : quatre pouvoirs restaient à exercer — RFC 1481
Deux pages peuvent orienter un réseau mondial sans configurer le moindre routeur. En juillet 1993, RFC 1481 donnait à CIDR un appui institutionnel net. Le texte nommait cependant ceux dont l’action manquait encore: responsables de l’adressage, fabricants de routeurs et…

Histoire d'Internet
Un seul composant pouvait faire parler tout l’agrégat : la délégation par procuration du RFC 1482
Dans l’exemple le plus révélateur du RFC 1482, le backbone pouvait entendre l’un de trois préfixes et annoncer aussitôt un bloc plus large. Cette règle rendait la table plus petite. Elle ne transformait pas le composant entendu en preuve que toutes les autres destinations du bloc…

Histoire d'Internet
Le nom figurait sous .US. La zone n’avait pas pour autant été déléguée : RFC 1480
Une réponse DNS positive semble clore la question: le nom existe. En 1993, cette réponse pouvait pourtant provenir de trois montages distincts sous `.US` — une fiche directe avec adresse IP, une fiche directe acheminant le courrier vers une passerelle, ou une branche réellement…

Histoire d'Internet
La route était annoncée. Cinq décisions réglaient encore son sort : RFC 1476
Entre « reçu » et « utilisé », un routeur peut cacher toute une politique. RFC 1476 en donnait une représentation étonnamment nette: l’annonce entrante devenait une candidate, puis traversait cinq choix locaux avant d’être installée, transformée, résumée ou montrée à un autre…

Histoire d'Internet
Le pont distant allait accepter la trame. C’était encore une conviction locale : RFC 1474
Une case `accept` apparaît dans la colonne distante d’un tableau de gestion. Elle semble décrire une capacité possédée par l’autre extrémité. RFC 1474 disait pourtant autre chose: l’entité locale *croit* que le pont distant acceptera ce type MAC. Cette nuance empêchait une…

Histoire d'Internet
Le prototype a sauvé la session Telnet. Il avait écarté la politique source : RFC 1477
Dans un compte rendu d’expérimentation, le sujet d’un verbe compte autant que le résultat. « Le prototype s’est adapté » ne signifie pas « toute l’architecture a été éprouvée ». RFC 1477 permet précisément de retrouver ce sujet: un logiciel instrumenté, un anneau de quatre…

Histoire d'Internet
Le réglage de compression avait changé. Il fallait redémarrer le lien pour qu’il compte : RFC 1473
Une écriture réussie n’est pas toujours un changement réussi. Dans la MIB PPP/IP de 1993, le gestionnaire pouvait choisir une compression, relire la table et obtenir des nombres parfaitement valides. Tant que l’IPCP n’était pas Opened et que le lien n’avait pas redémarré, ces…

Histoire d'Internet
Un identifiant voyageait dans le paquet. Le chemin, lui, n’y était pas : RFC 1475
Imaginez un journal réseau qui aligne trois valeurs de 64 bits pour le même datagramme. Elles diffèrent à chaque routeur. Ce n’est ni une corruption ni trois versions concurrentes d’un itinéraire. Dans TP/IX, chaque machine prêtait au paquet une poignée privée destinée à son…

Histoire d'Internet
La ligne de secret était « valide ». Aucun pair ne s’était encore authentifié : RFC 1472
Sur l’écran de gestion, le mot `valid` pouvait donner l’impression qu’une vérification venait d’aboutir. Dans la MIB de sécurité PPP de 1993, il disait autre chose: cette ligne de configuration pouvait être utilisée. Le pair, lui, n’avait peut-être encore envoyé aucun paquet…

Histoire d'Internet
Le jeu de caractères était déclaré. Le flux d’octets devait encore revenir à l’ASCII : RFC 1468
Avec `ISO-2022-JP`, le courrier japonais disposait enfin d’un nom portable. Mais ce nom ne dispensait aucun système de suivre l’histoire du flux: les séquences d’échappement changeaient l’interprétation des octets, chaque ligne devait retrouver un état simple, et les relais…

Histoire d'Internet
La table pouvait dater la route. Elle ne prouvait pas que le relais était prêt : RFC 1465
Dans l’exemple le plus révélateur du RFC 1465, une fiche datée du 18 décembre 1992 ne devait prendre effet que le 1er février 1993. Ce délai donnait aux administrateurs le temps de préparer leurs MTA. Il montrait aussi ce que le fichier partagé ignorait: qui l’avait reçu, qui…
