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.

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…

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…

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…

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.

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…

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…

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

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…

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…

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.

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…

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…

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.

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…

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.

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…

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…

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…

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…

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.
