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.

Entreprises centres de données Europe et Moyen-Orient
AZUR DATACENTER SAS : ce que l’inscription au répertoire des membres du RIPE NCC prouve — et ce qu’elle ne prouve pas
Une seule source publique figure dans le dossier de cette société française: une ligne dans l’annuaire des membres du RIPE NCC. Le briefing sépare méthodiquement ce que cette ligne établit de ce que le nom de l’entreprise laisse supposer.

Histoire d'Internet
RFC 2216 : le numéro du service n’était que l’adresse de sa promesse
Un service de réseau pouvait recevoir un numéro reconnu et rester encore presque entièrement à prouver. En 1997, RFC 2216 a transformé cette faiblesse en méthode: obliger chaque définition à révéler qui invoque quoi, quel trafic est couvert, où commence la police, comment les…

ICANN
4,3 millions d’IDN comptent des enregistrements, pas l’acceptation universelle
Un nom peut figurer dans le DNS et dans le total d’un registre, puis être refusé par le premier formulaire qui demande une adresse électronique. Le rapport 2026 de l’ICANN montre ces deux réalités à la fois: l’offre d’identifiants multilingues s’est élargie, mais leur parcours…

Histoire d'Internet
RFC 2345 : l’adresse proposée n’était pas l’identité de l’entreprise
En 1998, la recherche semblait pouvoir tenir dans un échange presque trivial: envoyer un nom d’entreprise, recevoir une URL et un libellé, puis ouvrir la page. La RFC 2345 expérimentait cette économie avec WHOIS. Elle rendait la découverte plus simple, mais ne transformait ni le…

Histoire d'Internet
RFC 2212 : le délai promis avait deux dettes, C et D
Deux routeurs peuvent réserver le même débit sans offrir la même borne de retard. En 1997, RFC 2212 a donné un nom à cette différence: une dette qui diminue quand le débit réservé augmente, `C/R`, et une dette temporelle qui demeure, `D`. La garantie devenait calculable, mais…

IETF
Un nom de nœud n’est pas une preuve d’identité
Une adresse partagée peut rendre une étape de traceroute indécidable. Le projet IETF consacré à l’identification du nœud propose d’ajouter une adresse ou un nom à certaines erreurs ICMP. Il améliore ainsi le contexte disponible, mais ouvre simultanément une surface de divulgation…

Histoire d'Internet
L’adresse n’était pas la liaison : ce que NHRP pouvait réellement établir selon RFC 2333
Dans un réseau NBMA, trouver l’adresse de la prochaine étape pouvait supprimer plusieurs détours IP. C’était la promesse de NHRP. Mais RFC 2333 n’en faisait ni une preuve de connexion ni un certificat de disponibilité. Le routage choisissait d’abord une direction; NHRP pouvait…

Histoire d'Internet
La cafetière répond. La tasse, elle, ne prouve toujours rien : RFC 2324
HTCPCP a donné à la cafetière une adresse, des verbes et des réponses mémorables. Il n’a pas donné à la réponse du serveur le pouvoir d’attester l’infusion, la remise d’une tasse, l’aptitude à boire ou la consommation réelle.

Histoire d'Internet
RFC 2210 : le bit qui retirait sa crédibilité au résumé du chemin
Un récepteur RSVP pouvait recevoir un objet riche en chiffres: nombre de sauts, bande passante, latence minimale, MTU, paramètres de service garanti. Mais RFC 2210 imposait de lire d’abord un seul bit. S’il signalait une rupture générale, les autres valeurs de l’ADSPEC devenaient…

IETF
Un accès Internet n’est pas une capacité : le reçu opérationnel proposé par la RFC 4084
Une offre peut porter le nom d’« accès Internet » tout en laissant ouvertes les questions qui déterminent l’exploitation réelle. La RFC 4084 invite à remplacer cette ambiguïté par un vocabulaire neutre; l’étape suivante consiste à en faire un reçu vérifiable.

Histoire d'Internet
La coupure de zone n’entrait pas dans le /26 : ce que le RFC 2317 a réellement délégué
Un préfixe IPv4 pouvait se terminer au vingt-sixième bit, alors que l’arbre inverse ne proposait une frontière naturelle qu’après un octet. Le RFC 2317 a comblé cet écart par une convention de noms et des CNAME dans la zone parente. Il n’a pas transformé cette convention en titre…

Histoire d'Internet
L’association était « mature ». Le résultat de sécurité ne l’était pas : RFC 2367
Une console locale peut présenter une association de sécurité IPsec complète: SPI, algorithmes, adresses, durée de vie et état `MATURE`. La RFC 2367 permet de lire précisément ce constat, mais elle interdit d’en agrandir silencieusement la portée. La ligne décrit un moteur de…

Dossier
Le pseudo-segment sans charge utile qui réécrit l’état TCP
Dans Presto, une correction découverte en fin de pipeline revient au début sous la forme d’un segment synthétique. Ce mécanisme peut faire autorité sur l’état de transport sans constituer des données utilisateur, une fin d’appel socket ou la preuve qu’une application a reçu quoi…

Histoire d'Internet
L’adresse disait « reste ici ». Seul le routeur traçait la frontière : RFC 2365
Une destination en 239/8 signale une portée administrative; elle ne construit pas le mur qui la fait respecter. La RFC 2365 a confié ce travail à des routeurs de frontière configurés interface par interface. Une règle absente, asymétrique ou mal exécutée suffit donc à transformer…

Dossier
Une adresse de résolveur ne suffit plus à raconter une résolution
En ajoutant un second serveur faisant autorité à une zone expérimentale, APNIC Labs a vu le nombre moyen de requêtes par test passer de 3,43 à 2,57. Ce résultat ne prouve pas pourquoi le comportement a changé. Il montre en revanche qu’une adresse publique de résolveur peut…

Histoire d'Internet
RFC 2188 : quand l’échec d’un côté ne dit pas ce que l’autre sait
Un exécutant envoie le résultat d’une opération réussie, puis reçoit plus tard une indication `FAILURE`. Pendant ce temps, l’invocateur peut déjà avoir accepté ce même résultat. Aucun des deux ne ment: RFC 2188 avait précisément conçu un protocole où l’efficacité, le choix de la…

Dirigeants
Adrian Farrel et le chemin que le réseau n’a pas encore accepté
Une réponse PCEP positive peut être exacte tout en précédant l’installation du moindre état de transfert. L’architecture PCE à laquelle Adrian Farrel a contribué permet de lire ce décalage comme une frontière, et non comme une anomalie.

IETF
BGP DRIP : quand un signal de risque prétend devenir une consigne de routage
Après un incident, la première question d’un responsable réseau devrait être simple: qui a décidé de réduire la préférence de cette route ? Avec le projet DRIP, la réponse pourrait traverser plusieurs systèmes — un détecteur, un routeur, un validateur RPKI, puis d’autres…

IETF
RFC 7872 : la perte était mesurée, la responsabilité restait incertaine
Une sonde qui disparaît fournit un fait. Elle ne désigne pas encore l’équipement, l’organisation ni l’intention qui l’a fait disparaître. RFC 7872 est surtout précieux parce qu’il garde ces niveaux séparés, alors même que ses mesures de 2014–2015 révélaient des pertes…

Histoire d'Internet
Le prix caché du deuxième fournisseur
Une entreprise croit acheter de la résilience lorsqu’elle commande un second circuit. RFC 2260 rappelle que ce doublon physique ne règle pas la question décisive: qui devra porter l’état de routage nécessaire au secours, et à quel moment ? Selon le choix retenu, la facture se…
