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
La zone qui frappa : DNS NOTIFY, IXFR et autorité à jour
Au début du DNS, un secondaire pouvait ignorer sa vétusté jusqu’au prochain contrôle. NOTIFY le réveilla; IXFR ne transmit que les différences.

Histoire d'Internet
L’adresse qui interrogea le câble : comment ARP rendit la joignabilité locale révisable
Une route IP peut désigner le prochain saut sans fournir l’adresse dont Ethernet a besoin. ARP combla cet intervalle par une question publique, une réponse locale et une mémoire qui ne devait jamais devenir éternelle.

Histoire d'Internet
La connexion qui devait prouver sa nouveauté : pourquoi TCP exige trois temps
Un segment peut atteindre le bon couple d’adresses et de ports tout en appartenant à une liaison déjà morte. L’ouverture TCP ne demande donc pas seulement « êtes-vous joignable ? »: elle oblige chaque extrémité à montrer qu’elle a vu le choix de séquence présent de l’autre.

Histoire d'Internet
Le paquet qui dut apprendre sa taille : comment la découverte du MTU de chemin déplaça la fragmentation vers les extrémités
L’émetteur ne voit pas le maillon le plus étroit de la route. Entre le routeur qui découpait silencieusement, le message ICMP qui signalait la limite et la sonde confirmée par le destinataire, l’Internet a déplacé la décision sans jamais confier le chemin entier à une seule…

Histoire d'Internet
Deux manières de ne rien trouver : comment le DNS a séparé NXDOMAIN de NODATA
Dans le DNS, une réponse vide n’est jamais une conclusion suffisante. Elle peut signifier qu’un nom entier manque, ou qu’un nom bien réel ne possède simplement pas le type d’enregistrement demandé. Toute l’histoire de la mise en cache négative tient dans l’effort pour ne pas…

Histoire d'Internet
L’erreur qui apprit à expirer : comment le DNS mit en cache ce qui n’existait pas
Une réponse vide n’est pas encore une preuve. Elle peut signaler un nom absent, un type d’enregistrement manquant, une panne, un silence ou une délégation à suivre. Le DNS ne put mémoriser ses échecs sans danger qu’après avoir donné au « non » un sujet précis, une autorité…

Histoire d'Internet
Le cœur qui devait cesser d’être le cœur : EGP et l’invention des systèmes autonomes
La décentralisation de l’Internet n’a pas commencé par l’égalité parfaite de ses réseaux. Elle a commencé par une séparation praticable: chaque administration pouvait garder son routage intérieur, tout en publiant une information limitée à ses voisins. EGP a rendu cette autonomie…

Histoire d'Internet
L’horloge née du désaccord : comment NTP a produit l’heure d’Internet sans serveur souverain
Une horloge peut répondre sans hésiter et se tromper de plusieurs heures. NTP est né de cette contradiction: sur un réseau où le trajet des paquets varie et où les oscillateurs dérivent, l’heure utile ne pouvait être une simple proclamation. Elle devait rester une estimation…

Histoire d'Internet
La carte dessinée par des paquets expirés : comment traceroute a fait de l’échec une preuve sur Internet
Un paquet qui meurt n’est normalement qu’une perte. En décembre 1988, Van Jacobson en fit une balise: en réglant sa durée de vie pour qu’il expire un routeur plus loin à chaque essai, puis en recueillant le message d’erreur, il obtint une carte locale sans demander de carte au…

Histoire d'Internet
Quand un routeur annonça les réseaux des autres : AS7007 et l’échec d’une confiance sans limites
Le résumé de veille Quand un routeur annonça les réseaux des autres: AS7007 et l’échec d’une confiance sans limites explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences…

Récits
Le RIPE NCC sépare l’avenir d’ENUM de 23 délégations en difficulté
Le projet de déclaration destiné à la réunion de septembre de l’UIT-T change l’échelle de la décision. Le RIPE NCC défend désormais le maintien d’ENUM public tout en proposant que 17 délégations apparemment inopérantes et six délégations partiellement défaillantes soient…

Histoire d'Internet
Le premier réseau devenu remplaçable : la retraite d’ARPANET et l’Internet qui continua
Lorsque ARPANET fut mis hors service en 1990, l’Internet ne disparut pas avec lui. Le réseau pionnier avait accompli quelque chose de plus durable que sa propre survie: la fonction d’interconnexion appartenait désormais à des protocoles, des routes et des opérateurs multiples…

Récits
LACNIC veut vérifier les anciens ROA avant d'attribuer de nouvelles adresses
La proposition LAC-2026-3 place un contrôle de sécurité au moment où il coûte le plus cher d'attendre: la demande de ressources supplémentaires. Avec un seuil de 80 % de couverture par des ROA valides, le principe tient en une phrase. Le calcul, le délai de correction et la…

Histoire d'Internet
La fenêtre qui apprit la retenue : comment TCP évita l’effondrement sans police du trafic
Face à la première grande crise de congestion, l’Internet n’a pas installé un répartiteur souverain au-dessus des réseaux. Il a appris à chaque émetteur TCP à écouter le chemin, à sonder sa capacité et à reculer avant que les retransmissions ne détruisent le débit utile.

Récits
APNIC place la joignabilité et le jugement au même ordre du jour
Faire parvenir un signalement au bon exploitant n’équivaut pas à décider qu’il y a abus. Deux propositions prévues pour le 10 septembre distinguent ces étapes, sans encore désigner la voie de recours lorsqu’elles produisent un désaccord.

Récits
La décision manquante après le vote 2026 du comité de révision de LACNIC
Le décompte est public, les périodes de contrôle sont closes et le résultat est déclaré officiel. Pourtant, la page du LACNIC qui mettait en jeu deux mandats ne désigne aujourd’hui qu’un seul candidat élu, sans préciser le sort du siège vacant à pourvoir immédiatement.

Récits
L’échéance des certificats AFRINIC s’est divisée en quatre horloges
L’avis du 18 août décrivait un seul basculement. L’exploitation en a produit quatre: la date annoncée, le code amont, la version portable et les exécutions réellement observables par les réseaux. Ces horloges n’ont pas sonné ensemble.

Créateurs
Eric Dumazet: les files d'attente cachées de Linux
TCP peut prendre une décision d'envoi raisonnable et perdre quand même du temps après que les paquets ont quitté son contrôle direct. Les travaux de Dumazet sur TCP Small Queues, la planification équitable des flux, le pacing et les structures de données optimisées pour le cache…

Histoire d'Internet
Vint Cerf avant le basculement : la frontière TCP/IP
Le passage d’ARPANET à TCP/IP n’a pas consacré l’œuvre solitaire d’un « père de l’Internet ». Il a mis à l’épreuve une architecture collective: des responsabilités déplacées vers les hôtes, des passerelles entre réseaux différents, des identifiants publiés, des logiciels révisés…

Tendances services cloud Amérique du Nord
EBS en 2011 : la capacité de reprise comme contrôle
La panne qui a touché Amazon EBS en avril 2011 ne se résume ni à une mauvaise manipulation réseau ni à une indisponibilité uniforme du cloud. Le basculement erroné du trafic, l’isolement de nœuds de stockage, la recherche simultanée de nouvelles répliques puis la saturation de…
