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.

Un port ne suffisait pas : RFC 675 a intégré le réseau au nom du socket

Histoire d'Internet

Un port ne suffisait pas : RFC 675 a intégré le réseau au nom du socket

Un service peut garder le même point d’entrée local tout en répondant à des interlocuteurs différents. RFC 675 nomme ces échanges par les deux sockets d’extrémité; la question du port local vient ensuite, quand il faut comprendre comment chaque nom reste distinct à travers les…

8 oct. 2026
La balise était un seul jeton, pas une carte de navigation : RFC 1766

Histoire d'Internet

La balise était un seul jeton, pas une carte de navigation : RFC 1766

RFC 1766 découpait une balise de langue en valeur principale et sous-balises séparées par des traits d’union, tout en demandant aux applications de traiter la chaîne entière comme un jeton. Cette structure ordonnait un espace de noms partagé; elle ne dessinait pas un parcours…

8 oct. 2026
Syslog pouvait signaler la qualité de son horloge. L’opérateur devait encore en définir les limites : RFC 5424

IETF

Syslog pouvait signaler la qualité de son horloge. L’opérateur devait encore en définir les limites : RFC 5424

Lorsqu’un incident se joue entre plusieurs machines, une heure affichée à la milliseconde donne facilement une impression de certitude. RFC 5424 prévoit justement un moyen de joindre au journal ce que l’émetteur sait — ou ne sait pas — de sa propre mesure du temps.

8 oct. 2026
Avec WAIS, un document pouvait nourrir la recherche suivante : la boucle de pertinence de la RFC 1625

Histoire d'Internet

Avec WAIS, un document pouvait nourrir la recherche suivante : la boucle de pertinence de la RFC 1625

Un lecteur pouvait saisir quelques mots, joindre un document — ou un simple passage — et demander à WAIS de trouver des textes similaires. La réponse était une citation classée, pas un ensemble de résultats conservé ni le document lui-même. La RFC 1625 décrit ce choix discret…

8 oct. 2026
La réussite du provisionnement ne décidait pas, à elle seule, de l’accès réseau : RFC 5422

IETF

La réussite du provisionnement ne décidait pas, à elle seule, de l’accès réseau : RFC 5422

La RFC 5422 distingue la préparation des identifiants de l’autorisation réseau; son mode sans authentification du serveur reste réservé au provisionnement.

8 oct. 2026
Qui choisissait l’adresse ? La RFC 4014 reliait l’autorisation RADIUS à DHCP

Histoire d'Internet

Qui choisissait l’adresse ? La RFC 4014 reliait l’autorisation RADIUS à DHCP

Une autorisation d’accès réussie ne fournit pas encore d’adresse IP. En 2005, la RFC 4014 a défini un passage étroit permettant à un serveur d’accès de transporter certains attributs RADIUS vers un échange DHCP ultérieur, sans confondre ces deux décisions.

8 oct. 2026
L’AAA connaissait l’abonné. Le Home Agent avait encore besoin d’une clé : RFC 5419

IETF

L’AAA connaissait l’abonné. Le Home Agent avait encore besoin d’une clé : RFC 5419

RFC 5419 explique pourquoi certains opérateurs de Mobile IPv6 souhaitaient s’appuyer sur leur relation AAA existante pour authentifier les abonnés. La question la plus révélatrice vient ensuite: le serveur AAA du réseau d’origine peut reconnaître l’abonné, mais le Home Agent…

8 oct. 2026
« Courant » ne voulait pas dire « sans examen » : le test de la RFC 6709

Histoire d'Internet

« Courant » ne voulait pas dire « sans examen » : le test de la RFC 6709

Une extension peut ajouter très peu de syntaxe et demander beaucoup de travail aux systèmes déjà en service. La RFC 6709 ne mesurait donc pas le caractère « courant » au nombre de lignes ajoutées. Elle le rattachait à une condition plus exigeante: le protocole de base et les…

8 oct. 2026
Moins de 1 % des UPDATE BGP liés au RPKI : un résultat utile, pas un verdict sur la stabilité

Récits

Moins de 1 % des UPDATE BGP liés au RPKI : un résultat utile, pas un verdict sur la stabilité

Une étude évaluée par les pairs estime que les mises à jour associées au RPKI restent marginales dans le volume observé des UPDATE BGP. Cela compte, mais le volume des messages n’épuise pas la question de la stabilité.

8 oct. 2026
L’authentification CAPWAP n’inscrivait pas l’équipement dans le réseau : RFC 5418

IETF

L’authentification CAPWAP n’inscrivait pas l’équipement dans le réseau : RFC 5418

L’analyse de RFC 5418 sépare l’authentification WTP–AC de l’appartenance à un déploiement, du rôle de l’équipement et du trajet des données. Une session valide ne répond qu’à une partie de la question opérationnelle.

8 oct. 2026
Un seul Internet, plusieurs opérateurs : l’analogie téléphonique de la RFC 1462

Histoire d'Internet

Un seul Internet, plusieurs opérateurs : l’analogie téléphonique de la RFC 1462

Pour rendre l’architecture lisible, le FYI de 1993 part d’un appel téléphonique: l’usager voit un service, tandis que des réseaux distincts exploitent et réparent chacun leur portion.

8 oct. 2026
Le NAT était une fonction, pas une interface : pourquoi le modèle de la RFC 4008 a dû changer

Histoire d'Internet

Le NAT était une fonction, pas une interface : pourquoi le modèle de la RFC 4008 a dû changer

Dans l’exemple de configuration de la RFC 4008, le gestionnaire SNMP crée d’abord une ligne associée à un `ifIndex`, puis y rattache des mappages. Dix ans plus tard, NATV2-MIB décrit la traduction comme une fonction logique qui peut traverser plusieurs interfaces. Entre les deux…

8 oct. 2026
La trame traversait le pseudowire, sans son rôle de service : RFC 7152

Histoire d'Internet

La trame traversait le pseudowire, sans son rôle de service : RFC 7152

En 2014, un mémo de l’IETF sur les exigences a mis au jour une lacune discrète des VPN de couche 2: un routeur de périphérie pouvait recevoir une trame Ethernet par un pseudowire sans savoir si elle provenait d’un accès racine ou feuille. La RFC 7152 a transformé ce manque de…

8 oct. 2026
Avant la découverte CAPWAP, DHCP ordonnait les contrôleurs que le WTP pouvait essayer : RFC 5417

IETF

Avant la découverte CAPWAP, DHCP ordonnait les contrôleurs que le WTP pouvait essayer : RFC 5417

Une option DHCPv4 ou DHCPv6 peut placer un contrôleur d’accès avant un autre dans la recherche initiale d’un point de terminaison sans fil. RFC 5417 définit cet ordre comme une préférence configurée; la découverte et DTLS déterminent ensuite quel pair peut devenir le point de…

8 oct. 2026
Sans AFI, la politique valait pour « any » : les quatre familles de RFC 4012

Histoire d'Internet

Sans AFI, la politique valait pour « any » : les quatre familles de RFC 4012

RPSLng a ajouté une clause facultative pour préciser la famille d’une politique multiprotocole. Son absence ne laissait pas la portée indéterminée: RFC 4012 lui donnait le sens « any », tandis que les anciens attributs conservaient leur sens IPv4 unicast.

8 oct. 2026
Le trafic des racines DNS a doublé ; l’indice venait d’une mise à jour de résolveur

Dossier

Le trafic des racines DNS a doublé ; l’indice venait d’une mise à jour de résolveur

Pendant environ une semaine, le débit de requêtes reçu par le DNS racine est passé d’environ 1,6 à 3,2 millions par seconde. Le trafic était valide et provenait de réseaux de résolveurs récursifs; les opérateurs n’ont constaté aucun effet mesurable sur le service racine.…

8 oct. 2026
RFC 5416 : la liaison 802.11 a une frontière d’époque

IETF

RFC 5416 : la liaison 802.11 a une frontière d’époque

RFC 5416 décrit une liaison CAPWAP précise pour IEEE 802.11. Elle organise les échanges entre le point de terminaison radio et le contrôleur, mais ne transforme pas un champ de capacité en garantie pour toutes les fonctions Wi-Fi ultérieures. Pour une décision de direction, il…

8 oct. 2026
L’état CAPWAP ne prouve pas le service : RFC 5415

IETF

L’état CAPWAP ne prouve pas le service : RFC 5415

RFC 5415 organise un plan de contrôle WLAN: un Access Controller gère des Wireless Termination Points, établit des sessions protégées, applique des réglages et transporte des données clients. Mais un état de protocole terminé, une session DTLS ou un paquet de données reste une…

8 oct. 2026
WiCoP est une archive historique, pas une base de déploiement : RFC 5414

IETF

WiCoP est une archive historique, pas une base de déploiement : RFC 5414

RFC 5414 décrit WiCoP, un protocole de contrôle et de provisionnement des grands réseaux WLAN. Le RFC Editor le classe Historic et renvoie à RFC 5415. La distinction est décisive: un contrôleur visible ou un accusé de réception ne prouve ni l’autorité actuelle, ni l’application…

8 oct. 2026
AS24940 : 91 routes, 63 correspondances et 49 autorisations plus larges

Récits

AS24940 : 91 routes, 63 correspondances et 49 autorisations plus larges

Le résumé de veille AS24940: 91 routes, 63 correspondances et 49 autorisations plus larges explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences possibles pour l’infrastructure.…

8 oct. 2026