Aller au contenu principal

Sujet

Preuves fondées sur les ressources réseau

Au sein de la facette Sujet, la veille thématique Preuves fondées sur les ressources réseau rassemble des articles qui partagent un même sujet, un même signal ou un même thème de suivi. Cette page offre aux lecteurs un parcours plus riche à travers les reportages associés, les preuves issues de sources publiques, les acteurs du marché et les implications pour l’infrastructure, avec suffisamment de contexte pour comprendre pourquoi le sujet compte pour les mouvements d’entreprises, les décisions de gouvernance, l’exposition régionale et le risque opérationnel. Les lecteurs peuvent comparer les signaux récurrents, les organisations concernées, les preuves publiques, le contexte du marché, la continuité de service, les achats, la concurrence, la conformité et les questions de planification stratégique liées au sujet, au lieu de se contenter d’une liste succincte d’articles correspondants. Elle explique ce que couvre le sujet, quels acteurs ou politiques de l’infrastructure sont impliqués, quelles preuves étayent la couverture et pourquoi le sujet peut être important pour les opérateurs, les clients, les investisseurs et les lecteurs de politiques publiques.

RFC 2187 : la hiérarchie des caches comme contrat opérationnel, pas comme carte du réseau

Histoire d'Internet

RFC 2187 : la hiérarchie des caches comme contrat opérationnel, pas comme carte du réseau

En décrivant l’usage d’ICPv2 dans les hiérarchies de caches Web, la RFC 2187 ne transforme jamais la proximité en autorité. Elle décrit une mécanique de délégation: qui peut répondre à quoi, sous quelles conditions, avec quels signaux et quel repli. Relue aujourd’hui, cette…

23 sept. 2026
RFC 2277 : l'étiquette a voyagé avec le texte, pas la compréhension

Histoire d'Internet

RFC 2277 : l'étiquette a voyagé avec le texte, pas la compréhension

Un document archivé ne peut pas négocier avec son futur lecteur. Il peut seulement conserver ses octets, déclarer leur jeu de caractères et, si le format le permet, indiquer une langue. RFC 2277 a transformé cette précaution en politique pour les spécifications de l'IETF. Mais…

23 sept. 2026
ICPv2 : un protocole de décision rapide fondé sur des indices, pas sur des preuves complètes

Histoire d'Internet

ICPv2 : un protocole de décision rapide fondé sur des indices, pas sur des preuves complètes

En 1997, ICPv2 répondait à un besoin très concret des caches Web: décider rapidement vers quel voisin se tourner lorsqu’un objet devait être récupéré. Son intérêt historique tient à la modestie de son modèle de preuve. Un HIT, un MISS, un silence UDP ou une mesure RTT peuvent…

22 sept. 2026
Le drapeau P déclenche la mesure, il ne prouve pas un chemin complet

IETF

Le drapeau P déclenche la mesure, il ne prouve pas un chemin complet

MPLS PBT-M demande aux nœuds capables et activés d’émettre une carte postale pour un paquet marqué. La sobriété sur le fil est réelle, mais la preuve de complétude se déplace vers les configurations, les exports, les compteurs de perte et le travail de corrélation du collecteur.

22 sept. 2026
Le tunnel ne faisait qu’un saut. Ses routes étaient doubles : RFC 2185

Histoire d'Internet

Le tunnel ne faisait qu’un saut. Ses routes étaient doubles : RFC 2185

Un routeur IPv6 pouvait voir une liaison point à point parfaitement simple alors que le paquet traversait, sous cette apparence, un réseau IPv4 calculant sa propre route. RFC 2185 isolait ainsi l’engagement décisif: IPv6 devait conduire le paquet vers le bon encapsulateur, puis…

22 sept. 2026
RFC 1644 : le SYN pouvait être recevable sans prouver l’exécution

Dossier

RFC 1644 : le SYN pouvait être recevable sans prouver l’exécution

Un compteur plus récent que celui gardé en mémoire suffisait à T/TCP pour remettre immédiatement les données d’un SYN au processus serveur. Cette décision gagnait un aller-retour au niveau transport; elle ne produisait pourtant aucun reçu attestant que l’application avait…

22 sept. 2026
Le registre est séparé. Le collecteur doit encore prouver ce qu’il a lu : RFC 9736

IETF

Le registre est séparé. Le collecteur doit encore prouver ce qu’il a lu : RFC 9736

RFC 9736 attribue enfin aux informations Peer Up de BMP leur propre registre TLV. La correction clarifie l’évolution du protocole; elle ne démontre ni la version déployée d’un parseur, ni la fidélité de son stockage, ni l’état du réseau observé.

22 sept. 2026
Trois serveurs DNS peuvent tomber comme un seul

Histoire d'Internet

Trois serveurs DNS peuvent tomber comme un seul

Une délégation peut afficher trois noms et ne disposer que d’un seul chemin de survie. Si les machines partagent une salle, une alimentation, un réseau local ou un fournisseur, le pluriel de la zone masque un point de défaillance commun. RFC 2182 a posé en 1997 une règle plus…

22 sept. 2026
L’enquête APNIC déplace le bilan de la formation vers le réseau en service

Récits

L’enquête APNIC déplace le bilan de la formation vers le réseau en service

Un atelier peut être excellent sans déboucher immédiatement sur une modification en production. L’enquête APNIC 2026 demande précisément de ne plus confondre ces deux résultats: les compétences sont appréciées, mais les répondants veulent des travaux pratiques, un accompagnement…

22 sept. 2026
Le dernier LIE a été accepté. Le fabric n’était pas encore prouvé : RFC 9719

IETF

Le dernier LIE a été accepté. Le fabric n’était pas encore prouvé : RFC 9719

Une télémétrie exacte peut devenir trompeuse dès qu’on lui fait dire davantage que ce qu’elle mesure. Avec RFC 9719, le dernier LIE accepté est un indice précis sur une interface RIFT, pas un certificat de bon fonctionnement du fabric.

22 sept. 2026
La boîte avait disparu du répertoire, pas de toutes les sessions : RFC 2180

Histoire d'Internet

La boîte avait disparu du répertoire, pas de toutes les sessions : RFC 2180

Un client avait reçu `OK` après la suppression de `FOO`. Un autre, déjà installé dans la boîte, pouvait encore lire et modifier son contenu. En 1997, RFC 2180 a traité cette divergence non comme une anomalie à masquer, mais comme le prix explicite d’une liberté d’implémentation…

22 sept. 2026
RFC 2174 : la route existait, mais le commutateur devait encore attendre

Histoire d'Internet

RFC 2174 : la route existait, mais le commutateur devait encore attendre

Dans le protocole SSP, le silence d’un commutateur pouvait être une action de sécurité. Une nouvelle route apparaissait, le plus petit numéro de commutateur devenait racine virtuelle, un port entrait dans la carte de diffusion — et pourtant aucune trame de broadcast ne devait…

22 sept. 2026
RFC 2171 : l’adresse suivait le port, pas la machine

Histoire d'Internet

RFC 2171 : l’adresse suivait le port, pas la machine

Sur un réseau MAPOS, un câble déplacé suffisait à changer la vérité portée par l’adresse. Le nœud restait le même, mais son nouvel attachement au commutateur lui donnait une autre valeur de couche liaison. Cette dépendance topologique était le mécanisme, non un défaut accidentel.

22 sept. 2026
Une table propre, un voisin qui détourne le trajet : la leçon BGP d’APNIC 62

Récits

Une table propre, un voisin qui détourne le trajet : la leçon BGP d’APNIC 62

Un réseau peut écarter une annonce d’origine invalide et acheminer malgré tout des paquets vers celui qui l’a émise, par l’intermédiaire d’un voisin moins strict. Le cas présenté à APNIC 62 oblige à distinguer la décision locale, la route choisie plus loin et les observations qui…

22 sept. 2026
RWhois pouvait indiquer le bon gardien sans authentifier sa fiche

Histoire d'Internet

RWhois pouvait indiquer le bon gardien sans authentifier sa fiche

Le piège de RFC 2167 tient à un dossier rangé dans une mauvaise branche: il existe quelque part, mais l'itinéraire prévu pour le retrouver ne passe pas par là. La distribution du Whois avait donc un problème de placement, distinct de la véracité des données.

21 sept. 2026
RFC 2143 : un bus rapide ne donnait pas à chaque hôte le droit de répondre

Histoire d'Internet

RFC 2143 : un bus rapide ne donnait pas à chaque hôte le droit de répondre

Sur une liaison SCSI, la vitesse pouvait séduire un concepteur de grappes de stations de travail. Mais partager un câble ne suffisait pas à constituer un réseau de pairs. La proposition de 1997 devait franchir deux seuils distincts: recevoir une commande venue d’un autre hôte et…

21 sept. 2026
Plusieurs alertes dans un même envoi, autant de décisions à prouver

IETF

Plusieurs alertes dans un même envoi, autant de décisions à prouver

Le projet multi-SET soumis à la dernière consultation de l’IESG promet de réduire le nombre de requêtes nécessaires à la circulation des événements de sécurité. Le gain de transport n’établit pourtant ni l’ordre des traitements ni la révocation effective d’un accès chez le…

21 sept. 2026
Une connexion TCP s'éteint, sa mémoire demeure : l'hypothèse du RFC 2140

Histoire d'Internet

Une connexion TCP s'éteint, sa mémoire demeure : l'hypothèse du RFC 2140

En 1997, une succession de petites connexions Web pouvait contraindre TCP à refaire sans cesse ses premières estimations. Joe Touch proposa de conserver certains résultats au niveau du couple de machines. Mais un temps de trajet observé n'est pas un état de session, et une…

21 sept. 2026
ACTN entre paquets et optique : deux avis demandent qui répond de l’état du réseau

IETF

ACTN entre paquets et optique : deux avis demandent qui répond de l’état du réseau

Un orchestrateur peut décrire toutes les étapes d’une modification et perdre pourtant la certitude de son résultat après un redémarrage. Deux évaluations de l’IETF, l’une consacrée à la sécurité et l’autre à l’exploitation, demandent au projet ACTN/POI de rendre cette incertitude…

21 sept. 2026
RFC 2133 : mêmes appels socket, autre contrat d’adresse

Histoire d'Internet

RFC 2133 : mêmes appels socket, autre contrat d’adresse

Garder `connect()` ne suffisait pas à rendre une application compatible avec IPv6. En 1997, RFC 2133 conservait le vocabulaire des appels tout en déplaçant l’effort vers la taille des adresses, la famille du socket et la manière d’interpréter les résultats.

21 sept. 2026