Domaine principal
Infrastructure Internet
Au sein de la facette Domaine principal, l'analyse Infrastructure Internet regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.
IETF
Dieter Sibold et le serveur horaire qui oublie ses clients
Un service NTP public ne peut pas conserver une session de sécurité pour chaque machine qui lui demande l'heure. La RFC 8915 résout ce problème par une rupture volontaire: TLS établit les clés, puis disparaît; le client rapporte ensuite l'état chiffré dont le serveur a besoin. Ce…
Histoire d'Internet
Le nom n’était pas l’adresse : comment RFC 814 a séparé l’identité de la route
Un hôte déménage, mais une ancienne table continue de lui attribuer son adresse précédente. La connexion réussit et atteint pourtant une autre machine. En 1982, RFC 814 a pris ce paradoxe au sérieux: le nom, l’adresse, la route et le port ne sont pas quatre façons équivalentes de…
Tendances FAI régionaux Europe et Moyen-Orient
Deux circuits fibre ne sont pas diversifiés tant que leurs parcours ne sont pas prouvés
Deux accès peuvent porter des numéros de circuit, des contrats et des logos différents tout en disparaissant sous le même coup de pelleteuse. La résilience commence par la connaissance des dépendances communes, pas par le nombre de fournisseurs sur une feuille d’achat.
IETF
David Lawrence et la réponse DNS qui survécut à son TTL
Une réponse DNS vient d'expirer alors que sa source autoritative ne répond plus. La RFC 8767 permet au résolveur récursif d'assurer une continuité limitée avec l'ancienne valeur, à condition d'avoir réellement tenté un rafraîchissement, de borner cette exception et de continuer à…
Histoire d'Internet
L’accusé de réception s’arrêtait à la liaison : comment PPP circonscrivait la fiabilité
PPP pouvait rendre une liaison plus fiable sans prétendre rendre tout le trajet certain. Avec RFC 1663, deux voisins pouvaient numéroter, acquitter et retransmettre leurs trames. L’accusé reçu attestait une progression locale; il ne certifiait ni l’identité du pair, ni la route…
Histoire d'Internet
La hiérarchie était en réalité un graphe : comment Gopher plaçait le prochain serveur dans chaque ligne de menu
L'écran promettait une arborescence paisible. Le réseau exécutait autre chose: une succession de décisions prises par des machines autonomes. Dans Gopher, une ligne de menu séparait le nom destiné au lecteur d'un sélecteur opaque, d'un hôte, d'un port et d'un type de transaction.…
IETF
Steve Sheng et le verrou qui n’a pas arrêté la maintenance DNSSEC
Un domaine peut rester « verrouillé » alors que son jeu de DS évolue sans fraude ni contournement. La RFC 10026 oblige à abandonner l’image d’un cadenas universel: il faut nommer l’acteur, le type de commande bloqué et la voie de maintenance authentifiée qui demeure ouverte.
Histoire d'Internet
Le rapport ne pouvait pas condamner la liaison : PPP laissait le seuil à chaque extrémité
Compter les paquets perdus ne suffit pas à dire qu’une liaison est mauvaise. Avec les Link-Quality-Reports, PPP a donné aux deux extrémités une comptabilité comparable des deux sens de circulation, tout en refusant d’imposer un seuil universel ou une procédure unique de coupure.…
Histoire d'Internet
Mohamed Awang Lah : diriger l’internet sans posséder tous les pouvoirs
Mohamed Awang Lah a exercé une influence technique et opérationnelle majeure sur les débuts de l’internet public en Malaisie. Mais son parcours montre aussi pourquoi une direction très visible ne doit pas être confondue avec l’autorité institutionnelle, la propriété d’une…
Histoire d'Internet
Un lien en cachait plusieurs : comment PPP Multilink donnait une seule séquence au faisceau
L’ajout d’une ligne ne devait pas obliger le réseau à recommencer sa conversation. PPP Multilink conservait les trames propres à chaque membre, mais plaçait leurs fragments dans un ordre commun au faisceau. Ce compromis disait au récepteur comment refaire le paquet sans imposer à…
Histoire d'Internet
Le succès qui rendait son propre flux caduc : comment XMPP redémarrait après TLS et SASL
Dans XMPP, réussir une négociation de sécurité ne permettait pas à l’ancien flux XML de poursuivre sa route. Cette réussite changeait au contraire les conditions de vérité du dialogue: la connexion TCP restait ouverte, mais les en-têtes, l’identifiant et les fonctions du flux…
Histoire d'Internet
Les caractères que la somme de contrôle n’a jamais vus : comment PPP nettoyait le trajet série avant de juger la trame
Sur une liaison série, tout octet observé n’appartient pas nécessairement à la trame voulue par l’émetteur. PPP a donc placé une frontière avant le contrôle d’intégrité: retirer l’habillage réversible du transport et quelques caractères de commande précisément désignés, puis…
Histoire d'Internet
L’en-tête qui n’apparaissait qu’en cas de gain : la décision locale d’IPComp
Une association IPComp pouvait être parfaitement valide et laisser passer le paquet suivant sans la moindre trace d’IPComp. Ce silence n’était pas une panne: lorsque la charge compressée et les quatre octets d’en-tête n’étaient pas plus petits que l’original, le protocole…
Histoire d'Internet
Le relais de datagrammes qui mourait avec un flux : comment SOCKS5 lia UDP à une association TCP
Un port UDP n’annonce jamais qu’une conversation est finie. SOCKS5 résolut ce manque sans inventer une fausse connexion entre les datagrammes: il fit dépendre le relais d’un dialogue TCP distinct. Quand ce dialogue disparaissait, l’autorité de relayer disparaissait avec lui, même…
Histoire d'Internet
La Key qui ne verrouillait rien : GRE a séparé le flux de la sécurité
Un champ de quatre octets s’est appelé Key avant de disposer d’une serrure, d’un secret ou d’une preuve d’identité. La normalisation de GRE n’a pas comblé ce vide par une promesse plus ambitieuse. Elle a donné au champ une fonction plus étroite: désigner un flux logique à…
Histoire d'Internet
L’octet que le rejet a su nommer : l’indice d’ICMP Parameter Problem
Un paquet rejeté ne disparaît pas toujours sans laisser d’adresse. Avec Parameter Problem, ICMP a donné au nœud qui abandonne l’analyse un moyen minimal de dire où elle s’est arrêtée. L’indice n’explique pas tout: il borne au contraire ce que le rapporteur sait, ce qu’il renvoie…
IETF
Peter Thomassen et la mise à jour qui exigeait chaque serveur faisant autorité
Dans le DNS, obtenir une réponse suffit souvent à poursuivre la résolution. Modifier une délégation exige une règle plus sévère: le parent doit savoir si la demande existe dans l’ensemble du service faisant autorité. Avec le RFC 9975, Peter Thomassen transforme cette différence…
Histoire d'Internet
Le premier paquet n’était qu’un candidat : comment RTP fit mériter la continuité
Un datagramme peut présenter toutes les apparences de la normalité: version correcte, type de charge connu, longueur cohérente, SSRC inédit. RTP ne lui accordait pourtant pas le droit de créer à lui seul l’histoire d’une source. Il fallait qu’un second paquet transforme une…
Histoire d'Internet
Le repère qui a survécu au chemin : comment NFS a rendu l’identité opaque et la péremption explicite
Dans un système de fichiers distribué, le nom indique où chercher; il ne suffit pas à dire ce que le serveur a trouvé. NFS a confié cette seconde fonction à un « file handle » opaque. Puis le protocole a précisé ce que ce repère devait traverser, ce qui pouvait le faire expirer…
IETF
Paul Hoffman et la copie de la racine qui ne répondait qu’à son propre hôte
Le service décrit par la RFC 8806 possède toute la zone racine, mais il lui est interdit de devenir un service pour le réseau. Il répond au résolveur installé sur sa propre machine, reproduit la racine publique sans la corriger à sa manière, valide les signatures et disparaît du…