Domaine principal
Infrastructure
Au sein de la facette Domaine principal, l'analyse Infrastructure 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.
Tendances FAI régionaux Europe et Moyen-Orient
Chez Ray-Svyaz, l’offre à 500 Mbit/s laisse le tarif de renouvellement à vérifier
À Sheregesh, MyCentra associe un débit annoncé de 500 Mbit/s à une remise de 50 %. La page officielle précise que cette remise dure trois mois avant le passage au tarif principal convenu lors du raccordement. Le prix du quatrième mois devient donc la première donnée économique à…
Histoire d'Internet
Quand l’identification IPv4 a cessé d’identifier chaque datagramme
*Dans IPv4, un champ peut rester présent dans chaque en-tête tout en perdant toute autorité sémantique pour une classe de trafic.*
IETF
Cesser de signer, continuer de lire : la RFC 9905 rend le retrait de SHA-1 asymétrique
La RFC 9905 modifie la règle DNSSEC au niveau des lignes d’algorithmes: les algorithmes SHA-1 concernés ne doivent plus servir à créer de nouveaux éléments, tandis que les implémentations de validation doivent continuer à les prendre en charge pendant la transition du parc…
IETF
La protection linéaire MPLS coordonne la commutation — mais les règles de priorité décident quelle demande l’emporte
Un point terminal du domaine de protection reçoit des demandes locales et distantes, les ordonne selon une priorité explicite, puis déplace les sélecteurs entre un chemin de travail et un chemin de protection préprovisionnés. La décision de direction ne consiste donc pas à…
Histoire d'Internet
La pièce jointe annonçait son type. La machine locale choisissait la commande : RFC 1524
Deux lecteurs de courrier pouvaient recevoir exactement les mêmes octets et ouvrir deux programmes différents. Ce n’était pas une anomalie du MIME: RFC 1524 avait volontairement placé la décision d’exécution dans une politique locale, là où un nom de format cessait d’être une…
IETF
QUIC : une limite de réception n'est pas le PMTU du chemin
Le paramètre annoncé par un pair indique ce qu'il est disposé à recevoir, et non la capacité du chemin entre les deux extrémités.
IETF
Quatre cases, une chaîne de confiance : la RFC 9904 transfère la politique algorithmique DNSSEC au registre
Pour chaque algorithme DNSSEC, quatre recommandations distinctes concernent l’implémentation du validateur, l’implémentation du signataire, l’usage pour la validation et l’usage pour la signature. La RFC 9904 déplace leur gestion vers les registres IANA, sans modifier au départ…
Histoire d'Internet
Le message était intact. Trois acteurs décidaient encore de son ordre de lecture : RFC 1556
Dans un courrier mêlant hébreu, anglais, chiffres et ponctuation, aucune lettre ne doit disparaître pour que la phrase change. En 1993, RFC 1556 a isolé ce défaut de preuve: MIME pouvait livrer les caractères, sans déterminer qui devait les mettre dans l'ordre à l'écran.
Histoire d'Internet
Pourquoi TCP a besoin d’un marqueur de fin et d’un no-op
Dans l’espace variable des options TCP, deux octets très simples séparent deux problèmes différents: savoir où s’arrête la liste utile et pouvoir déplacer l’option suivante sans imposer cette disposition au récepteur.
Histoire d'Internet
Le répéteur devait répondre avant de redémarrer : RFC 1516
La console recevait une réponse rassurante alors que le répéteur Ethernet n’avait pas encore commencé l’étape la plus incertaine. La RFC 1516 imposait que la réponse SNMP parte avant la réinitialisation disruptive. Elle séparait ainsi, dans le temps, l’accusé de réception…
Histoire d'Internet
Avant le choix d’IPng, Internet a interrogé ceux qui devraient en vivre les conséquences : RFC 1550
Un compteur électrique et une liaison radio ont précédé les schémas de paquets. Avec RFC 1550, l’IETF a choisi de recueillir les contraintes des futurs usages avant de laisser les protocoles candidats plaider leur cause.
Histoire d'Internet
L’alerte attendait, le compteur continuait : RFC 1515
Une console peut rester silencieuse alors que l’équipement vient de franchir deux fois le même seuil physique. La RFC 1515 avait prévu cette apparente contradiction: l’alerte devait patienter cinq secondes, mais l’état courant et le compteur d’entrées conservaient chacun leur…
Histoire d'Internet
La norme devait fonctionner même option coupée : RFC 1547
Sur une liaison facturée au volume, le paquet qui demande simplement « es-tu encore là ? » n'est pas gratuit. RFC 1547 est parti de ce genre de désaccord très concret pour poser une règle plus ambitieuse: le besoin local d'activer une fonction ne devait pas retirer à l'autre…
Histoire d'Internet
Le disque annonçait une capacité, l’application en recevait une autre : RFC 1514
Un inventaire matériel et une alerte d’espace libre peuvent parler de la même machine sans mesurer le même objet. En 1993, la RFC 1514 a inscrit cette prudence dans la Host Resources MIB: le support physique, la partition, le système de fichiers et la réserve effectivement…
Histoire d'Internet
Une adresse stable ne promettait pas le même serveur : RFC 1546
Deux paquets portent la même destination. Le premier arrive sur la machine X; le second peut revenir sur X ou partir vers Y. C'est par cette scène très courte que RFC 1546 a rendu visible, dès 1993, une frontière que l'exploitation masque facilement: l'adresse peut désigner un…
Histoire d'Internet
Un cran de plus, sans savoir combien de trames manquaient : RFC 1513
Le cadran passe de 41 à 42. Sur l’anneau, combien de trames ont disparu ? Le chiffre ne répond pas. Dans la RFC 1513, il signifie seulement que la sonde a détecté une nouvelle période où ses propres ressources ne suffisaient plus.
AFNOG
Le format pratique facultatif d’AfNOG ne précise pas les ressources nécessaires
L’appel AfNOG de 2007 permettait une partie pratique sans publier ses besoins matériels.
IETF
Les mesures de perte et de délai MPLS révèlent les performances sans prendre le contrôle du chemin
La mesure de performance MPLS transforme des indices d’acheminement en éléments exploitables: la mesure de perte calcule des écarts à partir de compteurs de paquets ou d’octets, tandis que la mesure du délai calcule des valeurs aller simple et aller-retour à partir d’horodatages…
Tendances mondiales des FAI régionaux
Chez RapidSeedbox, localiser le service suppose d’identifier qui annonce les routes
La documentation de RapidSeedbox distingue deux cas: l’entreprise peut router une plage vers son propre serveur dédié, tandis que le fournisseur du client annonce la plage utilisée sur un serveur externe, sur présentation d’une lettre d’autorisation. Un pays affiché ne suffit…
Histoire d'Internet
Pourquoi les numéros de séquence TCP reviennent à zéro
Un espace de numérotation fini peut néanmoins maintenir un ordre cohérent: TCP traite ses positions comme les points d’un anneau, non comme une suite entière illimitée.