Horizon temporel
Pluriannuel
Dans la facette Horizon temporel, les analyses à horizon temporel Pluriannuel sont organisées selon la période pendant laquelle un signal devrait rester pertinent. La page aide à distinguer les changements opérationnels immédiats des évolutions à plus long cycle — gouvernance, investissements, normes et infrastructures — qui peuvent s’étendre sur plusieurs trimestres ou années. Elle relie les hypothèses de calendrier aux preuves publiques, aux acteurs concernés, au contexte de marché, à l’exposition des clients, à la pression réglementaire et à la planification des infrastructures, afin que le lecteur puisse déterminer si un développement est urgent, stratégique ou encore en attente d’éléments de confirmation. Elle explique aussi comment l’horizon temporel modifie le sens d’un signal, quelles organisations peuvent être exposées et quelles décisions d’infrastructure appellent une action à court terme ou un suivi à long terme.
Dossier
Le routeur ne comprenait pas l’attribut, alors il l’a transmis : le bit Partial de BGP et l’autorité de l’ignorance
Dans un scénario d’exploitation illustratif, le routeur de transit a respecté le protocole. Il a reçu une route portant un attribut optionnel transitif inconnu, conservé les octets opaques, activé Partial et propagé l’annonce. Le routeur suivant connaissait le type, a jugé sa…
Histoire d'Internet
Le message mesuré avant de partir : comment SMTP SIZE avança le refus
Le SMTP d’origine pouvait transporter un message entier avant d’apprendre que le serveur ne le garderait jamais. L’extension SIZE ne promit pas la livraison: elle permit à deux relais de confronter une charge annoncée à une capacité locale avant d’en payer tout le transfert.
Tendances centres de données Europe et Moyen-Orient
La Grande-Bretagne veut faire garantir jusqu’à 712 500 £ par MW demandé aux centres de données
La place dans la file électrique britannique pourrait cesser d’être une option presque gratuite. Le projet d’Ofgem impose du capital et des preuves, mais ni une garantie bancaire ni un transformateur commandé ne font à eux seuls un centre de données viable.
Dossier
Le préfixe était IPv4, le chemin passait par IPv6 : RFC 8950 et l’autorité d’un next hop inter-familles
Dans un scénario de migration explicatif, le compte rendu ne contient que du vert: sessions BGP Established, capability 5 visible dans les OPEN, préfixes IPv4 toujours présents. Pourtant, un rack ne joint plus un client IPv4. La route existe, mais son next hop IPv6 est résolu…
Histoire d'Internet
Le réseau a répondu à la place de l’origine : pourquoi HTTP avait besoin de 511
Un client a interrogé un serveur et reçu la réponse du réseau intermédiaire. HTTP 511 a tenté de nommer cette substitution sans céder au portail l’identité de l’origine. Ses limites expliquent le passage ultérieur vers une API captive annoncée et authentifiée.
Dossier
La clé suivante était annoncée, mais pas livrée : TCP-AO et l’autorité d’une époque de clés
Dans un scénario explicatif de relève, à 2 h 07, le tableau de bord passe au vert. Les deux routeurs BGP affichent la clé 42 et une capture montre `RNextKeyID=42`. L’équipe en déduit que la relève est achevée, puis supprime la clé 17. Quelques secondes plus tard, les…
Histoire d'Internet
Quand la stabilité a retardé le rétablissement: l’histoire du route flap damping
Une route BGP pouvait être de nouveau valide et rester pourtant inutilisable pendant une heure. Le route flap damping avait été conçu pour protéger les processeurs des routeurs des années 1990; en mémorisant les changements sans en connaître la cause, il a aussi donné à des…
Histoire d'Internet
Le serveur qui cessa de rappeler : comment le FTP passif franchit le pare-feu
Le FTP ne fut pas adapté aux pare-feu par une refonte spectaculaire. Une décision plus modeste suffit: le serveur attendrait le second appel au lieu de le lancer. Ce renversement conserva les deux voies du protocole tout en redonnant aux extrémités la charge de savoir à qui elles…
Dossier
Le paquet est arrivé sans aucune marge : BGP GTSM et l’autorité de la proximité
Dans un scénario explicatif, le routeur n’a pas « perdu BGP ». Il a refusé des segments TCP parfaitement routables parce qu’ils arrivaient avec une unité de Hop Limit de moins que prévu. Après une bascule de maintenance, le trajet retour comptait désormais trois sauts; le contrat…
Histoire d'Internet
La requête était trop grande avant même son corps : pourquoi HTTP avait besoin de 431
Une requête HTTP peut être refusée avant la lecture de son contenu. Ce n'est pas qu'Internet ait fixé une taille universelle: un récepteur a décidé quelle quantité de contexte de contrôle il acceptait de traiter. Le code 431 a rendu cette limite locale intelligible.
Histoire d'Internet
L’hôte qui apprit une petite table de routage : comment IPv6 classa les premiers sauts
IPv6 ne transforma pas chaque terminal en routeur. Il permit d’exposer quelques choix temporaires, puis laissa l’hôte combiner préfixe le plus long, joignabilité observée et politique locale. La limite faisait partie du mécanisme.
Dossier
Le filtre a traversé la session, pas la frontière : BGP ORF et le droit de demander moins
Le client remplace la table complète par quelques centaines de préfixes dans sa liste d’import. Son RIB s’allège aussitôt. Rien ne prouve pourtant que le fournisseur a cessé de calculer, mettre en file et transmettre les centaines de milliers d’updates rejetés à l’arrivée.…
Histoire d'Internet
Le serveur qui comptait avant de répondre : pourquoi HTTP a eu besoin de 429
Le cinquante et unième appel peut être aussi correct que les cinquante précédents et recevoir pourtant un refus. HTTP 429 a rendu cette décision compréhensible sans prétendre définir l’identité comptée, la portée du quota ni la justice du partage.
Dossier
La session était Established mais ne transportait aucune route : RFC 8212 et l’autorité de la politique explicite
Le nouvel edge reste `Established`, échange des KEEPALIVE et ne reçoit pourtant aucune route IPv4 utilisable. Le transport fonctionne; le droit d’importer et d’exporter n’a pas été accordé. Le RFC 8212 transforme ce silence en règle de sûreté: une adjacence externe ne devient pas…
Histoire d'Internet
Le silence qui autorisa une adresse : ce que DAD pouvait prouver
IPv6 DAD fonda une décision importante sur une absence observée: aucun rival ne se manifesta pendant une épreuve locale et bornée. Restait à limiter la portée de ce silence.
Dossier
La session s’est tue en laissant une raison : le message d’arrêt BGP et le pouvoir d’expliquer une rupture
À l’heure prévue, le peering tombe. Le journal du voisin ne contient pas seulement `Cease`, mais une référence de changement, une cause et une durée estimée. Cette phrase peut éviter une fausse alerte. Elle peut aussi être forgée, exposée, mal affichée ou prise pour la preuve…
Dossier
Deux connexions avaient atteint OPEN, une seule pouvait rester : collision BGP et autorité d’un identifiant stable
Les deux routeurs appellent au même instant. Deux connexions TCP aboutissent entre les mêmes adresses et chacune transporte un OPEN BGP valide. Rien n’est cassé au niveau du transport. Pourtant, un peering configuré ne peut pas conserver deux machines d’états concurrentes. BGP en…
Histoire d'Internet
L’écriture qui devait nommer son passé : pourquoi HTTP a eu besoin de 428
Une requête peut être valide, autorisée et pourtant trop ignorante pour modifier une ressource. Avec 428, l’origine peut exiger qu’elle dise d’abord sur quel état antérieur repose sa décision.
Histoire d'Internet
Le nom choisissait le service : DNS SRV et ses hôtes
Un domaine menait autrefois vers une adresse et un port supposé. DNS SRV a rendu la localisation du service explicite, multiple et limitée.
Dossier
Le voisin continuait d’émettre mais ne recevait plus : BGP SendHoldTimer et le droit de clore une session à sens unique
Une session BGP peut rester Established tout en cessant d’être une relation d’échange. Les KEEPALIVE du voisin arrivent encore et rafraîchissent le HoldTimer, mais sa fenêtre de réception TCP est nulle: aucun retrait local ne franchit la frontière. Le voyant vert décrit alors une…