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
Prolonger une réservation sans la vérifier
Pour alléger RSVP, une extension a remplacé la répétition des descriptions complètes par des listes d’identifiants. Une réservation pouvait ainsi rester active sans que son contenu soit présenté à nouveau. Le gain était réel dans son principe; la capacité de réparation, elle…

Histoire d'Internet
La réponse que SMTP ne pouvait diviser : LMTP et la remise par destinataire
À la frontière de la remise locale, un même message peut rencontrer plusieurs réalités. Une boîte l'accepte, une autre manque temporairement de quota. SMTP ne dispose que d'un verdict final pour la transaction entière. LMTP a rendu ce verdict pluriel et ordonné, afin que la file…

Récits
Quand 174 se déclare 173 — l’identité non résolue d’une proposition APNIC
`prop-174: Align implementation of Prop-125 in APNIC Policy (APNIC-127)` `prop-173: Align implementation of Prop-125 in APNIC Policy (APNIC-127)`

Histoire d'Internet
Rappeler un client ne suffit pas à le reconfigurer
Une notification envoyée n'est pas une modification achevée. L'histoire de FORCERENEW, puis de son authentification par nonce, montre comment DHCP a donné au serveur l'initiative d'un nouvel échange sans lui permettre d'en escamoter les conditions.

Dossier
Le VPN était prêt, mais son intérêt n’était pas arrivé
Une route VPN peut exister chez son émetteur sans être annoncée à un PE dont toutes les sessions BGP sont établies. Avec le RFC 4684, l’intérêt pour un Route Target remonte vers la source tandis que la route correspondante revient en sens inverse. L’absence de route peut donc…

Dossier
Le domaine enfant a parlé. Qui rend le DS réel ?
Publier des enregistrements CDS et CDNSKEY signés ne modifie pas la zone parente. Entre l’intention de l’opérateur enfant et la confiance observée par un validateur se trouvent une décision, une publication et des caches qu’aucun accusé de réception ne peut confondre.

Histoire d'Internet
Philip F. Smith et le rapport de routage qui pouvait observer, non commander
Une table BGP ne dit pas à elle seule comment l’Internet devrait être exploité. Elle montre ce qu’un routeur donné a retenu à un instant donné. En lançant le Routing Report en 1999, Philip F. Smith a fait de cette vue partielle un instrument public durable: assez précis pour…

Récits
MyAFRINIC v2 ne peut pas signer quatre réceptions à la fois
AFRINIC a placé quatre trajectoires de politique derrière un même chantier logiciel; pour que la mise en service reste vérifiable, chacune doit conserver son propre statut, son propre essai d'acceptation et sa propre voie de correction.

Histoire d'Internet
Le lien que l’origine demanda de retirer : pourquoi HTTP 410 n’était pas 404
Une adresse peut cesser de répondre sans que le Web sache si elle reviendra demain, si elle est cachée ou si son retrait est décidé. Avec 410, HTTP a permis au serveur d’origine de transformer une absence incertaine en déclaration de retrait probable — tout en laissant aux…

Histoire d'Internet
SCTP : renoncer à envoyer ne suffit pas à faire avancer l’autre
Un expéditeur peut décider qu’un message ne mérite plus une tentative. Son correspondant, lui, ne peut pas deviner cette décision dans le silence du réseau. L’extension de fiabilité partielle de SCTP a donné une forme commune à ce renoncement, sans le transformer en preuve de…

Dossier
Zéro ne dit pas ce qui est faux
Dans BGP, la valeur zéro peut décrire une origine IGP parfaitement valide, un identifiant d’AS interdit ou une déclaration RPKI de non-routage. Le RFC 7607 ne demande donc pas une réaction uniforme: il oblige l’opérateur à conserver le champ, puis à refuser exactement l’objet qui…

Dossier
Qui règle l’horloge du renouvellement ? ACME ARI et le dernier kilomètre du remplacement
Une autorité de certification peut ouvrir une journée entière au renouvellement et voir pourtant tous les clients se présenter à la même minute. ACME Renewal Information coordonne une fenêtre; il ne remplace ni l’ordonnanceur local, ni le déploiement, ni la preuve fournie par le…

Récits
Avant le solde : le reçu de provenance dont AFRINIC aurait besoin
Un bloc IPv4 récupéré entrerait d’abord dans le `Recovered Pool`, zone administrative temporaire du mécanisme proposé. Son étape suivante dépendrait de son histoire: retrouver la catégorie de son pool d’origine, l’y renvoyer, répartir proportionnellement un bloc partiel ou, faute…

Dossier
La réponse disait « succès ». Aucun client n’avait changé : DHCPv6 Reconfigure et l’autorité d’un déclencheur
Un relais peut signaler une modification, un serveur l’accepter et un message authentifié atteindre un terminal sans que la nouvelle configuration soit encore devenue réalité. DHCPv6 Reconfigure est précieux parce qu’il sépare précisément ces étapes.

Dossier
La route a survécu au routeur qui la promettait
Avec le Long-Lived Graceful Restart, BGP peut conserver pendant des heures une route apprise d’un voisin dont la session a disparu. Ce délai protège parfois la continuité; il peut aussi prolonger une promesse de livraison dont le fondement opérationnel n’existe plus.

Histoire d'Internet
Deux enveloppes pour une adresse qui ne changeait pas
Le paquet conserve son expéditeur, mais change de façon de se présenter au réseau. Dans Mobile IPv4, le tunnel inverse a permis de séparer l’adresse que devait reconnaître le correspondant de celle que pouvait accepter le réseau visité. Cette distinction paraît discrète. Elle a…

Histoire d'Internet
Le prix d’un compte rendu augmente avec ceux qui l’écoutent
Dans une session audio multicast, accueillir davantage d’auditeurs ne multiplie pas nécessairement les voix émises. En revanche, demander à chacun un compte rendu à fréquence constante multiplie les messages de contrôle. RTCP a dû résoudre ce paradoxe: pour rester informé sur une…

Dossier
Le paquet était valide, mais deux sessions correspondaient : RADIUS CoA et le pouvoir de modifier une connexion active
Une demande de contrôle correctement protégée arrive sur un équipement d’accès. Elle vise un nom d’abonné et demande un nouveau filtre. Deux sessions actives portent ce nom. L’authentification du paquet est terminée; la décision sur la session ne fait que commencer.

Récits
La continuité comme preuve : le registre annuel que RIPE-862 appelle sans encore le fournir
`Internet Resilience, Scalability and Routing Security` → groupe d’objectifs de service `Technical Resilience and Security` → objectif `Security` → métrique `Internet Number Resources covered by ROAs and ASPA` → engagement, coût et responsable du futur Activity Plan and Budget…

Histoire d'Internet
Le record que le récepteur ne pouvait pas contenir : quand TLS a localisé la limite
Dans TLS, produire un gros record et en recevoir un ne coûtent pas forcément la même mémoire. Il a fallu près de quinze ans pour que la négociation cesse de confondre ces deux capacités.
