inetdoc.net

En première approximation, on peut assimiler le terme Stateful à un mode de communication avec un mécanisme de suivi d'état. Ce mécanisme est implanté sur un équipement qui assure la correspondance entre les flux sortants et entrants qui le traversent. La mémorisation des adresses présentes dans les en-têtes des différents protocoles permet de construire des tables de correspondances des flux réseaux. De très nombreux services, historiquement liés au protocole IPv4, sont basés sur ces mécanismes de suivi d'état : attribution des paramètres réseaux d'un hôte (DHCP), traduction d'adresse (NAT), pare-feux, balance de charge, redirecteurs, service mandataire (proxy), etc.

Le défaut de ce mode de communication le plus souvent évoqué est relatif à la nécessité d'un point d'enregistrement unique pour tous les flux. On parle alors du fameux Single Point Of Failure ou SPOF. En effet, si l'équipement Stateful unique est défaillant ou si il subit un déni de service, tous les flux réseaux seront bloqués. Pour pallier à ce défaut, les fonctions des services Stateful ont été étendues : les pare-feux peuvent partager leurs tables de suivi d'état, les serveurs DHCP peuvent partager l'état des baux délivrés aux postes clients, etc.

Le propos de ce document est de remettre en question l'enregistrement de l'état des flux réseau. Dans un Internet qui contient plus d'objets connectés que de dispositifs manipulés directement par des humains, il devient illusoire de chercher à identifier, référencer et enregistrer les paramètres de toutes les interfaces de tous les hôtes raccordés au réseau. On peut voir cette mise en cause du mode de communication Stateful comme un retour aux origines de l'Internet ; un réseau à commutation de paquets dans lequel tout hôte est susceptible de communiquer avec n'importe quel autre hôte.

Si les mécanismes de suivi d'état au niveau des couches transport, réseau et liaison sont remis en question, il sera toujours nécessaire de s'authentifier auprès d'un service pour identifier la source et la destination d'un flux d'informations. Dans les démonstrations ou les publicités sur les objets connectés, les capteurs transmettent leurs informations directement sur les réseaux sociaux. Avec ces exemples, l'identification et/ou l'authentification se fait au niveau application et non au niveau liaison avec l'enregistrement de l'adresse MAC de l'interface réseau dans un serveur DHCP.

Avec l'abandon de l'enregistrement des paramètres réseau des couches basses liées à la transmission de l'information, on autorise une plus grande dynamique dans les communications réseau. Le nombre des hôtes présents dans les domaines de diffusion peut varier librement et on déplace les fonctions d'enregistrement (identification, authentification, etc.) vers la couche application liée au traitement de l'information.

Pendant très longtemps, la bonne pratique voulait que l'on cherche à découper les réseaux en périmètres fonctionnels. À l'intérieur d'un périmètre on est sensé avoir une connaissance exhaustive des flux et des hôtes en présence. Dans cette optique, les services Stateful ont été naturellement mis en avant. Ils sont le point de passage obligé qui garantit que seules les fonctions assignées au périmètre sont présentes.

Même si ce modèle a encore de beaux jours devant lui, il est sûr qu'il va falloir évoluer dans le mode de conception des architectures. Côté Parc, le nombre et la nature des hôtes croît sans cesse. Avec cette croissance, l'idée même de la liste exhaustive des hôtes autorisés s'envole. Même en connectant les services DNS et DHCP statiques à l'aide d'applications spécifiques, il devient difficile de suivre la dynamique du nombre d'hôtes. Côté infrastructure, la virtualisation apporte aussi une dynamique inconnue jusqu'alors. Les outils de gestion intégrée des hyperviseurs permettent l'ajout et la suppression d'instances de serveurs virtuels très rapidement. Là encore, les outils classiques d'enregistrement manuel des entrées ne suivent pas la cadence.

Face à ce manque de réactivité du réseau, la bonne pratique de conception a évolué et on parle de plus en plus souvent de «VLANs d'étage» montrant ainsi que l'étendue du domaine de diffusion prévaut sur le découpage fonctionnel. Cependant, l'enregistrement des paramètres d'interface réseau perdure même s'il est sérieusement bousculé par les modes du style Bring Your Own Device ou BYOD. Dans de nombreux contextes professionnels, le contrôleur de domaine constitue encore le point d'enregistrement ultime, alors que dans le même temps, de plus en plus de flux transitent vers le Cloud. Ce fameux Cloud est aujourd'hui le principal «opposant» au modèle périmétrique.

L'autoconfiguration, telle qu'elle est présentée dans le document RFC4862 ne couvre pas la même liste d'attributs qu'un service DHCP basique. L'absence de configuration du resolver DNS a cruellement fait défaut dans l'adoption de cette solution. En effet, tout dispositif raccordé à un réseau a nécessairement besoin d'utiliser des noms pour identifier les hôtes à contacter. L'autoconfiguration strictement limitée à la couche réseau s'est avérée bloquante dans les usages. Le fait qu'il faille ajouter un programme supplémentaire dans la couche application est un frein important dans la mesure où il génère un surcoût d'administration.

Un nouveau document, RFC6106 IPv6 Router Advertisement Options for DNS Configuration, est venu compléter la liste des attributs «propulsés» par le service d'autoconfiguration avec la désignation du ou des serveurs DNS. Il date de 2010 et son adoption n'a pas été aussi rapide qu'escompté. À titre d'exemple, il semble que la fonction ne soit disponible que dans la version XE du système IOS de Cisco™ au moment de la rédaction de ces lignes.

Les fonctions du document RFC6106 sont utilisées dans la maquette présentée dans les sections suivantes. Elles font clairement apparaître la nécessité d'une configuration aux deux extrémités en communication. Les mêmes échanges de paquets RA (Router Advertisements) sont utilisés pour passer les paramètres mais une application spécifique doit appliquer la configuration du resolver DNS.