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.

Dossier
Le filtre de journaux choisit les questions de demain
Avec RFC 9742, la configuration de syslog devient plus comparable entre équipements. Cette langue commune ne garantit pourtant pas que les éléments nécessaires à une enquête survivront à l’incident.

IETF
Un horodatage en chemin rapide n’est pas une mesure authentifiée
Un horodatage peut être récent, précis et techniquement bien placé sans attester celui qui l’a produit. Les projets SPRING consacrés à STAMP sur SRv6 et SR-MPLS proposent justement de faire écrire l’heure de réception dans le chemin rapide, afin de multiplier les sessions et de…

Récits
RIPE NCC fait signer l’ASPA avant de montrer les fournisseurs qu’il observe
Le titulaire d’un AS peut désormais publier une autorisation cryptographique de ses fournisseurs, mais la documentation de RIPE NCC précise que le tableau de bord ne lui indique pas quels fournisseurs sont visibles dans BGP. L’aide utile ne serait pas une liste réputée vraie: ce…

Récits
Chez RIPE, la porte d’entrée NRTMv4 lit une réplique avant que le repli puisse agir
Le choix d’épargner la base principale est défendable. Le commit publié par le RIPE NCC montre toutefois que la vérification du nom intervient en amont du mécanisme capable de relire la notification sur la base maîtresse.

IETF
Un indicateur FRR non activé ne dit pas quelle politique locale a prévalu
Dans un réseau RSVP-TE, l’ingress peut formuler une exigence très précise pour le chemin de secours et recevoir, en retour, un silence d’un seul bit. Ce silence n’établit ni l’absence de protection ni la cause de l’écart. Il signale surtout que la décision a changé de niveau: la…

Dossier
RFC 9744 : le coût d’une panne que le tunnel ne désigne plus
La mutualisation des tunnels VPWS allège les ressources de transport. Elle ne dispense pas l’opérateur de savoir quelle liaison client doit être rétablie, ni quel chemin peut réellement la remplacer.

Récits
Les données 2026 d’AFRINIC écrivent « volontaire » de deux façons
Le résumé de veille Les données 2026 d’AFRINIC écrivent « volontaire » de deux façons 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 l’infrastructure. Le…

IETF
Un contact RDAP vérifié exige un périmètre de diffusion, pas un badge universel
Le mot « vérifié » inspire une réponse binaire: oui ou non, vert ou rouge, fiable ou douteux. Or une donnée d’enregistrement n’est jamais vérifiée dans l’absolu. Un attribut précis a été contrôlé, à une date donnée, par un acteur donné et selon une méthode donnée. Il reste encore…

Dossier
RFC 9746 : le coût de compatibilité d’un segment EVPN
Le choix de la méthode anti-boucle reste conditionné par les autres entités. L’arrivée d’un équipement utilisant la valeur par défaut peut rendre à nouveau nécessaires les étiquettes que les voisins avaient économisées.

IETF
Une mise à jour BGP authentifiée n’est pas un registre d’admission de tunnel SD-WAN
Dans un réseau automatisé, le vert se propage plus vite que la preuve. Une session BGP protégée reçoit une annonce valide, le réflecteur la diffuse, puis l’interface résume toute la chaîne par un état rassurant. Pourtant, entre l’identité du pair, son droit à annoncer…

IETF
Une carte de ports modifiable exige une trace de dérogation
Un orchestrateur retient un point de raccordement, suit une référence et aboutit sur un port physique. Ce geste paraît purement technique. Pourtant, dans le projet IVY soumis au dernier appel de l’IETF, cette référence peut provenir d’une découverte automatique ou d’une saisie…

IETF
Un percentile BMP reste local tant que sa méthode d’échantillonnage ne l’accompagne pas
Deux routeurs peuvent publier « P95 » dans le même type de message, sur une fenêtre de même durée et avec le même nombre d’observations, sans avoir mesuré la même réalité. Le protocole transporte le résultat. La comparabilité dépend encore de décisions locales que le résultat ne…

Histoire d'Internet
RFC 2056 : quand une URL ouvre une interaction Z39.50
En 1996, RFC 2056 a inscrit la recherche et la récupération Z39.50 dans la syntaxe des URL sans effacer l’état de session, les choix du client ni l’autorité locale du serveur.

Dossier
RFC 9747 : une boucle locale ne donne pas mandat sur le service distant
En dispensant le voisin de participer à BFD, l’Echo non affilié simplifie la détection. L’exploitant local hérite toutefois de la définition du test, de son calendrier et de la responsabilité d’en tirer une décision limitée.

IETF
« IPv6 uniquement » décrit un périmètre, pas un certificat de retrait d’IPv4
Une liaison d’accès peut ne transporter nativement qu’IPv6 tandis que le client atteint encore des destinations IPv4 par traduction. Ailleurs, le plan de contrôle, l’administration hors bande ou certains serveurs restent en double pile. Dire « IPv6 uniquement » peut donc être…

Histoire d'Internet
RFC 2041 : ce qu’un trajet mobile peut transmettre au laboratoire
En 1996, des chercheurs proposaient de transporter les observations d’un réseau mobile vers un banc d’essai filaire. Entre le trajet enregistré et les contraintes rejouées par le logiciel, une conversion étroitement encadrée décidait de ce qui devenait une preuve reproductible.

Récits
Un registre RIR exact n’a pas corrigé une erreur Geo-IP en deux mois
Un incident présenté à APNIC 62 rappelle une limite souvent masquée par le mot « donnée »: le registre peut être exact sans que la correction atteigne le service qui décide du pays d’un internaute.

IETF
Un résultat CoSERV valide ne prouve pas l’exhaustivité
Une requête parfaitement déterministe produit une réponse signée, liée à cette requête et encore dans sa période de validité. Le contrôle cryptographique réussit. Il reste pourtant impossible d’en déduire que le serveur a exploré un fonds complet ou renvoyé tout ce qui pouvait…

Récits
Chez ARIN, rattacher un ticket à un Org ID ne vaut pas décision de l’organisation
Un champ de formulaire peut résoudre une vraie difficulté opérationnelle tout en créant une apparence trompeuse. Le sélecteur d’Org ID ajouté à Ask ARIN donne enfin aux équipes le contexte qui leur manquait et conserve l’échange dans l’historique pertinent. Mais le lieu de…

Histoire d'Internet
Le descripteur vide raccourcissait la liaison, pas le contrôle d’accès
Deux échanges pouvaient précéder la première opération NFS utile: découvrir un port RPC, puis demander à MOUNT de convertir un chemin exporté en descripteur. En 1996, le RFC 2054 proposa de commencer par l’hypothèse la plus probable et de réserver les anciens échanges aux cas où…
