Résumé

  • La RFC 8799 reconnaît que certains protocoles peuvent être normalisés pour un périmètre technique restreint sans devoir fonctionner partout sur l'Internet ouvert ; elle exige en contrepartie que l'appartenance, les rôles de bordure, les fuites et les rencontres entre domaines soient traités comme des problèmes explicites.
  • Brian Carpenter partage la signature du texte avec Bing Liu. Cette Independent Submission informative expose des exigences de conception, mais ne constitue ni un consensus de l'IETF, ni une norme Internet, ni un protocole d'adhésion prêt à déployer.

Le jour où deux réseaux privés se rencontrent

Dans le premier réseau, une valeur locale désigne une classe de service prioritaire. Dans le second, la même valeur répond à une convention différente. Chacun est cohérent tant qu'il reste seul. Lorsqu'une passerelle relie les deux ensembles, le paquet demeure parfaitement formé et pourtant son sens devient faux. Une équipe croit préserver une promesse ; l'autre applique une règle qu'elle n'a jamais acceptée.

Cette scène résume une difficulté que le mot « privé » masque souvent. Une adresse, un pare-feu ou une couleur sur un schéma peuvent décrire l'intention d'un opérateur. Aucun de ces éléments ne prouve à lui seul qu'un nœud est membre, qu'une interface regarde vers l'extérieur ou qu'une autorisation ancienne a été retirée. Le protocole a besoin d'éléments qu'il puisse vérifier, pas seulement d'une organisation que les humains reconnaissent.

La RFC 8799, publiée en juillet 2020, nomme cet espace le « domaine limité ». Il peut tenir dans un bâtiment ou un véhicule, mais aussi relier des sites éloignés par un réseau virtuel. Usine, campus, tranche réseau, centre de données, réseau de capteurs ou service géré : la géographie ne définit pas la catégorie. Ce qui compte est une portée dans laquelle exigences, comportements ou significations diffèrent du reste de l'Internet.

Le texte emploie aussi « environnement contrôlé ». Le mot domaine n'y désigne pas le DNS. Il n'aborde pas davantage le morcellement politique ou linguistique de l'Internet. Carpenter et Liu cherchent à concilier deux réalités techniques : des usages locaux légitimes existent, tandis que l'Internet ouvert doit rester le moyen universel d'interconnexion.

Une portée restreinte n'est pas une dispense

Une chaîne industrielle soumise à un délai strict n'a pas les mêmes contraintes qu'une application grand public. Un capteur économe ne peut pas toujours payer le coût d'un mécanisme universel. Un opérateur peut donner à un identifiant une valeur qui n'existe que dans son propre réseau. La RFC 8799 admet donc que certaines fonctions n'ont ni besoin ni vocation à traverser l'Internet entier.

Elle refuse cependant le raccourci selon lequel une fonction locale pourrait rester vague. Des milliers de domaines distincts peuvent acheter les mêmes équipements auprès de plusieurs fournisseurs. Ils ont encore besoin d'une syntaxe et d'un comportement communs. Même hors connexion, deux appareils doivent se comprendre. Et un domaine isolé aujourd'hui peut être imbriqué, fusionné ou confié demain à un autre opérateur.

Le qualificatif local impose alors une preuve supplémentaire. Il faut dire où commence la signification, où elle cesse et comment un équipement hors portée se comporte. Une erreur de configuration ou une route par défaut peut faire sortir des bits dont l'apparence est banale mais dont le sens est privé. La RFC prévient qu'un usage limité n'excuse ni une mauvaise conception ni une sécurité faible ; il peut au contraire compliquer le modèle de confiance.

Quatre passages, quatre responsabilités

La section 5 distingue quatre situations qu'un cahier des charges ne devrait pas confondre.

Dans la première, le protocole local conserve des formats IP ordinaires. Deux parties éloignées d'un même domaine peuvent communiquer à travers l'Internet, qui transporte les paquets sans connaître leur sens aux extrémités.

Dans la deuxième, le mécanisme emploie une forme IP non standard, par exemple un en-tête d'extension IPv6 non standard. Il ne peut plus supposer que le chemin ouvert sera transparent. L'opérateur doit prévoir un transport ou un confinement adapté.

Dans la troisième, la fonction est déclarée invalide hors de son domaine d'origine. Un tunnel peut réunir des sites en un seul domaine virtuel, mais les nœuds de bordure doivent jeter tout paquet qui tenterait de sortir. Ce rejet n'est pas une précaution ajoutée après coup ; il appartient au fonctionnement correct.

Dans la quatrième, deux domaines attribuent des sens différents au même champ. Les valeurs DSCP l'illustrent : un paquet reste syntaxiquement valable, mais l'interopérabilité sémantique exige un accord entre opérateurs ou une traduction par passerelle. Une fusion sans cartographie peut transformer deux réseaux sains en un seul système incohérent.

Ces cas posent trois questions différentes. Les bits peuvent-ils traverser ? Ont-ils le droit de sortir ? Le voisin saura-t-il les interpréter ? Les réponses commandent tunnel, abandon, traduction, version et essais. La mention commerciale « compatible avec un domaine limité » ne répond à aucune d'elles.

Remplacer le contour par des relations vérifiables

La proposition la plus féconde de la RFC 8799 est qu'une frontière dessinée n'a pas, en elle-même, de sens technique. Ce qui importe est l'appartenance d'un nœud et son éventuel rôle de bordure. Sur une même machine, une interface peut regarder vers l'intérieur et une autre vers l'extérieur. Un émetteur doit distinguer une destination interne ; un récepteur peut devoir reconnaître l'origine du trafic.

Le document énumère alors onze fonctions. Le domaine possède un identifiant unique et vérifiable, assimilable à une clé publique. Un nœud établit son éligibilité, s'enrôle de manière sûre et reçoit des justificatifs d'autorisation. L'enrôlement doit pouvoir être annulé ; l'appartenance peut être intermittente. Les rôles, les pairs et les nœuds de bordure doivent être vérifiables. Enfin, les membres doivent recevoir politiques et configuration, notamment les filtres qui empêchent les paquets inappropriés de sortir.

L'imbrication et le chevauchement interdisent de réduire cette réalité à une seule variable « dedans/dehors ». Un appareil peut participer à plusieurs domaines sur des interfaces différentes. Une tranche peut se trouver dans un domaine d'opérateur ; un domaine d'observabilité peut croiser un domaine de service. L'autorité s'attache donc à un domaine, une interface, un rôle et une durée précis.

La révocation vaut autant que l'admission. Un système qui sait prouver comment un appareil est entré, mais pas qu'il est parti, accumule des exceptions invisibles. Le détenteur de la clé privée devient un point de confiance pour les opérations du domaine. Il n'obtient pas pour autant une autorité illimitée : la garde, la délégation, la rotation et la récupération de cette clé doivent elles-mêmes être gouvernées.

Carpenter et Liu ne fournissent pas le protocole complet. Ils laissent à de futurs travaux le marquage éventuel des paquets et leur authentification individuelle. Leur liste est un instrument d'analyse, non un logiciel à installer. Cette incomplétude déclarée empêche de confondre besoin architectural et solution acquise.

L'IOAM rend la bordure observable

La RFC 9197 apporte un cas ultérieur. L'IOAM ajoute ou met à jour des informations d'exploitation dans les paquets utilisateurs pendant leur traversée du réseau. Le mécanisme vise explicitement des domaines limités au sens de la RFC 8799.

Un même ensemble peut contenir plusieurs espaces de noms IOAM qui se chevauchent. Les concepteurs d'encapsulation doivent retenir les données dans le domaine visé et l'opérateur doit protéger la sortie, par exemple au moyen de filtres. Les équipements du bord ajoutent ou retirent les champs. Le contour abstrait devient ainsi une transformation de paquet confiée à des nœuds identifiables.

La RFC 9378 détaille les rôles. Un nœud d'encapsulation insère les options, des nœuds de transit les mettent à jour et le nœud de décapsulation situé en bordure retire toutes les options et les en-têtes associés. Un équipement peut jouer des rôles différents selon l'espace de noms. La preuve porte donc sur la fonction dans un contexte donné, pas sur l'étiquette permanente de la machine.

L'absence de fuite ne suffit pas à valider le déploiement. L'IOAM augmente la taille des paquets ; la distribution ECMP, la marge de MTU du chemin et le traitement ICMP peuvent changer. Il faut observer ce qui s'est passé dans le domaine autant que ce qui en est sorti.

Cet exemple montre que le vocabulaire de 2020 a trouvé un usage opérationnel. Il ne démontre pas que toutes les exigences générales de la RFC 8799 disposent désormais d'une solution universelle. L'identité du domaine, l'autorité des rôles et l'enrôlement sûr restent des choix à établir pour chaque système.

Une carte volontairement inachevée

L'University of Auckland présente Brian Carpenter comme professeur honoraire spécialisé dans les protocoles Internet et l'histoire de l'informatique. Son parcours comprend le réseau du CERN, les standards chez IBM et la présidence passée de l'IETF, de l'IAB et de l'Internet Society. Le Datatracker de l'IETF inscrit la RFC 8799 dans une production bien plus vaste.

Ce prestige ne doit pas changer le statut de la preuve. Le texte est une Independent Submission informative écrite avec Bing Liu. Il résulte de recherches nourries par des discussions à l'IETF, sans constituer le consensus de l'IETF ni une norme Internet. Les RFC ultérieures peuvent adopter sa définition sans modifier rétroactivement cette nature.

Sa force tient précisément à cette retenue. Les auteurs décrivent un problème avant de lui attribuer une solution universelle. Ils donnent aux ingénieurs une langue commune pour parler des significations locales, puis indiquent les surfaces d'autorité qu'un projet doit encore remplir.

La leçon durable est simple : « local » décrit une portée, pas une sécurité. Le domaine devient crédible lorsque l'on peut prouver qui en fait partie, qui contrôle sa sortie, quel sens s'arrête à la frontière et ce que les paquets ont réellement fait.

Sources