Dans le protocole de routage BGP, les annonces de routes sont marquées avec l'AS d'origine et avec les AS qui ont relayé l'annonce. Dans ce chemin des AS, on pouvait indiquer un ensemble d'AS, l'"AS_SET" (ainsi que l'"AS_CONFED_SET"). C'était déconseillé depuis le RFC 6472 et ce nouveau RFC 9774 l'interdit désormais. Le but est de simplifier BGP et notamment ses mécanismes de sécurité. Il faut maintenant forcément indiquer une suite ordonnée d'AS, une "AS_SEQUENCE".

Les textes de loi (et assimilés : décrets, par exemple) ne sont pas évidents à trouver et donc à citer. Ce RFC crée un espace URN (RFC 8141), "lex", pour pouvoir identifier les textes juridiques. S'il est largement adopté par les juristes (ce n'est pas gagné…), il facilitera les références aux textes légaux. Ainsi,"urn:lex:fr:etat:loi:2011-03-22;2011-302" pourrait identifier la loi n° 2011-302 portant diverses dispositions d'adaptation de la législation au droit de l'Union européenne en matière de santé, de travail et de communications électroniques (https://www.legifrance.gouv.fr/loda/id/JORFTEXT000023751262), par exemple (elle change entre autres le régime appliquable aux noms de domaine).

Aujourd'hui, sur l'Internet, on n'utilise plus (ou, en tout cas, cela devrait être le cas) que des algorithmes de chiffrement AEAD (Authenticated Encryption with Associated Data). Ils assurent confidentialité et intégrité des données. Mais on peut être gourmand et vouloir en plus d'autres propriétés. Ce nouveau RFC classe ces propriétés et définit la terminologie.

Un message HTTP est traditionnellement représenté comme du texte mais ce RFC spécifie une alternative, une représentation binaire d'un message.

Le titre fait référence à la Mésopotamie, étymologiquement « entre deux fleuves ». Ce livre (https://www.hodder.co.uk/titles/moudhy-al-rashid/between-two-rivers/9781529392128/) (en anglais) présente divers aspects de la vie dans la Mésopotamie antique, à travers plusieurs personnes dont les noms et les activités ont franchi les siècles, grâce à une invention géniale : l'écriture.

On le sait, un des problèmes stratégiques de l'Internet est l'absence d'un protocole de messagerie instantanée standard et largement répandu. Autant le courrier électronique fonctionne relativement bien entre logiciels différents, autant la messagerie instantanée est un monde de jardins clos, incompatibles entre eux, et qui nécessite d'installer vingt applications différentes sur son ordiphone. L'interopérabilité reste un objectif lointain. Il n'y a pas de solution simple à ce problème mais le système MLS (Messaging Layer Security) vise à au moins fournir un mécanisme de sécurité pour les groupes, mécanisme qui peut ensuite être utilisé par un protocole complet, comme XMPP (RFC 6120). MLS est normalisé dans le RFC 9420 et cet autre RFC, le RFC 9750, décrit l'architecture générale.

Si vous suivez l'actualité du routage sur l'Internet, vous avez peut-être vu des messages comme quoi on atteindrait bientôt « un million de routes ». Mais ça veut dire quoi et, surtout, est-ce que ce chiffre a un sens ?

Cela peut sembler étonnant, mais le service des News fonctionne toujours. Et il est régulièrement perfectionné. Ce nouveau RFC normalise une extension au format des articles qui permettra de sécuriser un petit peu l'opération d'annulation d'articles.

Les objets connectés, vous le savez, sont une source d'ennuis et de risques de sécurité sans fin. Non seulement ils ne sont pas forcément utiles (faut-il vraiment connecter une brosse à dents au réseau ?) mais en outre, comme ils incluent un ordinateur complet, ils peuvent faire des choses auxquelles l'acheteur ne s'attend pas. Pour limiter un peu les risques, le RFC 8520 normalisait MUD (Manufacturer Usage Description), un mécanisme pour que le fournisseur du machin connecté documente sous un format analysable les accès au réseau dont l'objet avait besoin ce qui permet, par exemple, de configurer automatiquement un pare-feu, qui va s'assurer que la brosse à dents ne se connecte pas (https://www.ietf.org/blog/mud/) à Pornhub. Dans un fichier MUD, les services avec lesquels l'objet communique sont typiquement indiqués par un nom de domaine. Mais le DNS a quelques subtilités qui font que l'utilisation de ces noms nécessite quelques précautions, décrites dans ce nouveau RFC.

Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau avant qu'il ne tente de se connecter à un serveur. On peut envoyer ainsi des indications sur les versions des protocoles gérées, des clés cryptographiques ou des noms de serveurs supplémentaires.

Dans les discussions au sujet du réseau Internet, on voit souvent passer des demandes sur l'AS associé à une adresse IP ou bien le contraire. Mais les questions simples du genre « de quel AS dépend une adresse IP ? » sont… trop simples.

On 15 and 16 March 2025, I was at the DNS hackathon 2025 (https://labs.ripe.net/author/becha/join-the-dns-hackathon-2025/) in Stockholm, organised by RIPE NCC, DNS-OARC (https://www.dns-oarc.net/) and Netnod. I worked on a mechanism to synchronize the caches of DNS resolvers.

Dans le contexte de la surveillance massive qui s'exerce contre les utilisateurices de l'Internet, tout identifiant un peu stable peut être utilisé pour pister quelqu'un. On en laisse, des traces ! C'est par exemple le cas avec l'adresse MAC. Ce nouveau RFC décrit les mécanismes existants pour diminuer le risque de pistage par l'adresse MAC. Il ne spécifie pas un protocole, il liste les solutions.

Vous savez que les types de médias comportent un type de premier niveau et un sous-type. Dans "image/gif", "image" est le type de premier niveau et "gif" le sous-type. On crée des sous-types tout le temps mais les types, l'identificateur qui est au premier niveau, c'est bien plus rare. La création du type "haptics (https://www.iana.org/assignments/media-types/media-types.xml#haptics)" (données haptiques), qui a été faite dans le RFC 9695, a été l'occasion de formaliser un peu plus le processus de création de types de médias.

L'enregistrement d'un nouveau type de média de premier niveau est plutôt rare (le dernier avait été "font/" en 2017). Notre RFC introduit le type "haptics/", pour les formats de fichier des interfaces haptiques, celles qu'on touche et qui vous touchent (une manette de jeu vidéo à retour d'effort, par exemple).

Successeur du RFC 6855, voici la normalisation de la gestion d'Unicode par le protocole IMAP (dans sa version 4rev1) d'accès aux boîtes aux lettres.

Ce nouveau champ de l'en-tête HTTP sert à indiquer que la ressource demande va être (ou a été) abandonné et qu'il faut penser à migrer. Il sert surtout pour les API HTTP.

La lutte contre la congestion du réseau est une tâche permanente des algorithmes utilisés dans l'Internet. Si les émetteurs de données envoyaient des octets aussi vite qu'ils le pouvaient, sans jamais réfléchir, l'Internet s'écroulerait vite. Des protocoles comme TCP ou QUIC contiennent donc des algorithmes de contrôle de la congestion. Il y en a plusieurs, certains peuvent être néfastes, et ce RFC, qui remplace le RFC 5033, explique comment de nouveaux algorithmes doivent être évalués avant d'être déployés en vrai. Bref, la prudence est nécessaire.

Le protocole ACME, surtout connu via son utilisation par l'AC Let's Encrypt, permet de prouver la « possession » d'un nom de domaine, pour avoir un certificat comprenant ce nom. Ce court RFC spécifie une extension à ACME qui permet de prouver la « possession » d'une adresse IP, ce qui permettra d'obtenir via ACME des certificats utilisant une adresse.

Le langage CDDL, qui permet de créer un schéma formel pour des formats comme CBOR, peut s'étendre via l'ajout d'« opérateurs de contrôle ». Ce RFC en spécifie quelques uns, notamment pour agir sur du texte ou convertir d'une forme dans une autre.