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.

AZUR DATACENTER SAS : ce que l’inscription au répertoire des membres du RIPE NCC prouve — et ce qu’elle ne prouve pas

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.

23 sept. 2026
RFC 2216 : le numéro du service n’était que l’adresse de sa promesse

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…

23 sept. 2026
4,3 millions d’IDN comptent des enregistrements, pas l’acceptation universelle

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…

23 sept. 2026
RFC 2345 : l’adresse proposée n’était pas l’identité de l’entreprise

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…

23 sept. 2026
RFC 2212 : le délai promis avait deux dettes, C et D

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…

23 sept. 2026
Un nom de nœud n’est pas une preuve d’identité

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…

23 sept. 2026
L’adresse n’était pas la liaison : ce que NHRP pouvait réellement établir selon RFC 2333

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…

23 sept. 2026
La cafetière répond. La tasse, elle, ne prouve toujours rien : RFC 2324

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.

23 sept. 2026
RFC 2210 : le bit qui retirait sa crédibilité au résumé du chemin

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…

23 sept. 2026
Un accès Internet n’est pas une capacité : le reçu opérationnel proposé par la RFC 4084

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.

23 sept. 2026
La coupure de zone n’entrait pas dans le /26 : ce que le RFC 2317 a réellement délégué

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…

23 sept. 2026
L’association était « mature ». Le résultat de sécurité ne l’était pas : RFC 2367

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…

23 sept. 2026
Le pseudo-segment sans charge utile qui réécrit l’état TCP

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…

23 sept. 2026
L’adresse disait « reste ici ». Seul le routeur traçait la frontière : RFC 2365

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…

23 sept. 2026
Une adresse de résolveur ne suffit plus à raconter une résolution

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…

23 sept. 2026
RFC 2188 : quand l’échec d’un côté ne dit pas ce que l’autre sait

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…

23 sept. 2026
Adrian Farrel et le chemin que le réseau n’a pas encore accepté

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.

23 sept. 2026
BGP DRIP : quand un signal de risque prétend devenir une consigne de routage

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…

23 sept. 2026
RFC 7872 : la perte était mesurée, la responsabilité restait incertaine

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…

23 sept. 2026
Le prix caché du deuxième fournisseur

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…

23 sept. 2026