Le masque que le silence fit mal deviner : comment ICMP amorça un sous-réseau

Résumé

• RFC 950 ajoutait Address Mask Request et Reply à ICMP pour qu’un hôte au démarrage apprenne le masque de 32 bits de son LAN ; en l’absence de réponse, le repli classful restait une hypothèse réparable, explicitement susceptible d’être fausse.
• RFC 1122 réservait les réponses à un agent explicitement configuré : apprendre un masque ne donnait pas le droit de le publier, et seule la première réponse acceptée modifiait l’hôte.
• DHCP a ensuite livré le masque au sein d’une configuration plus large tout en offrant des options pour activer ou couper les anciens rôles de découverte et de fournisseur ; RFC 6918 a finalement déprécié les types 17 et 18.

Le même silence recouvrait trois réseaux différents

RFC 950 ne commence pas par supposer que le masque est visible dans l’adresse. Une organisation pouvait choisir combien de bits de sa partie locale représentaient un sous-réseau. Le masque de 32 bits séparait donc une décision administrative locale de l’identifiant IPv4 mondial.

Cette décision avait un effet immédiat. Un hôte masquait sa propre adresse et celle de la destination. Si les résultats coïncidaient, il tentait une livraison directe ; sinon, il choisissait une passerelle. Un mauvais masque ne constituait pas une simple erreur d’affichage : il changeait la frontière entre voisin et route distante.

Un fichier stable pouvait fournir la valeur. La difficulté concernait les stations sans disque qui recevaient leur système par le réseau. Elles avaient souvent besoin, au même moment, d’une adresse, d’une passerelle, d’un serveur de noms et du masque. RFC 950 préférait déjà une acquisition groupée auprès d’un serveur d’amorçage, mais définissait aussi une question séparée pour le masque.

Si cette question restait sans réponse après plusieurs essais, trois réalités étaient compatibles avec le même silence. Le réseau pouvait être isolé de façon permanente. Il pouvait ne pas employer de sous-réseaux. Ou bien toutes ses passerelles pouvaient être provisoirement en panne. Aucun bit absent ne permettait de choisir entre ces scénarios.

Le repli était une action, pas un verdict

Pour continuer à fonctionner, l’hôte utilisait le masque correspondant au numéro de réseau Internet, c’est-à-dire l’interprétation non sous-réseautée de l’ancien adressage par classes. RFC 950 présentait ce choix comme le plus prudent dans l’incertitude.

La prudence avait une limite clairement dite. Ce masque pouvait se révéler erroné. Le texte estimait qu’il n’empêcherait pas les transmissions qui auraient autrement réussi, mais ne transformait pas l’absence d’agent visible en preuve que l’administrateur n’avait créé aucun sous-réseau.

Le protocole traitait donc le silence comme une autorisation opérationnelle très étroite : adopter un défaut réversible. Il ne lui accordait pas la valeur d’un renseignement positif sur la topologie.

Cette distinction rend le mécanisme plus intéressant que son format. Un système obligé d’avancer peut prendre une décision de secours sans prétendre avoir appris la vérité qui lui manque.

Une diffusion locale posait la question

Le scénario normal commençait par un Address Mask Request diffusé sur le LAN. Une passerelle, ou un hôte jouant son rôle, répondait avec le masque du sous-réseau où la demande avait été reçue. Si l’émetteur ne connaissait pas encore son adresse et plaçait zéro dans le champ source, la réponse était elle aussi diffusée.

Le message comprenait Type, Code, Checksum, Identifier, Sequence Number et un Address Mask de 32 bits. Le Code valait zéro. Les numéros ultérieurement inscrits dans le registre sont 17 pour Request et 18 pour Reply.

Identifier et Sequence pouvaient aider à rapprocher une question et une réponse. Pourtant RFC 950 permettait de ne pas effectuer ce rapprochement, car il supposait qu’un LAN ne possédait qu’un masque valable. Plusieurs passerelles pouvaient répondre sans créer de choix, et une réponse diffusée demeurait utile même si son origine logique n’était pas rattachée à une requête particulière.

L’hypothèse simplifiait l’échange tout en concentrant le risque. Le masque était une propriété collective de l’interface, pas une préférence individuelle. Si les réponses divergeaient, le problème n’était plus la corrélation des messages mais la rupture de la configuration commune.

Le retour de l’agent réparait les démarrages passés

RFC 950 ne laissait pas l’hôte prisonnier de son défaut. Lorsqu’une passerelle revenait, elle devait diffuser spontanément un Address Mask Reply. Un hôte dont le masque supposé différait de la valeur annoncée devait se corriger.

La réponse non sollicitée découplait la réparation de la fenêtre de demande. La station pouvait avoir cessé ses retransmissions depuis longtemps. L’agent n’avait pas à retrouver une ancienne question : son redémarrage publiait à nouveau le fait local.

Le même texte interdisait cependant à tout hôte ou à toute passerelle de répondre à partir d’une valeur devinée. Cette interdiction empêchait la panne d’un agent de transformer chaque consommateur en nouveau fournisseur d’une rumeur.

Un défaut pouvait donc servir à l’usage privé de l’hôte, mais pas fonder une déclaration destinée aux autres. La résilience ne passait pas par la réplication incontrôlée de l’autorité.

L’autorité n’accompagnait pas la donnée

RFC 1122 a donné une forme normative nette à ce principe. Un système ne devait envoyer une réponse que s’il était un agent faisant autorité pour les masques. Ce rôle devait résulter d’une configuration explicite.

Un hôte comme une passerelle pouvait être choisi. La nature de la machine n’était donc pas décisive ; l’acte administratif l’était. Une machine dotée d’un masque statique pouvait disposer d’un indicateur distinct disant si elle devait répondre.

La règle la plus révélatrice concernait la transmission de l’autorité. Recevoir un Address Mask Reply ne conférait aucun droit de réponse. Le masque appris ne devait pas servir de base à des Reply ultérieurs.

RFC 1122 justifiait cette sévérité par l’expérience : des hôtes envoyant avec désinvolture des masques invalides avaient causé de sérieux ennuis. Une valeur plausible ne suffisait donc pas ; le répondant devait avoir été sélectionné par une action administrative explicite.

Le paquet ne prouvait toutefois pas cette sélection par cryptographie. La spécification définissait l’acteur autorisé ; la protection du LAN, la configuration et le contrôle de l’implémentation devaient rendre ce rôle effectif.

La première réponse l’emportait, puis la porte se fermait

RFC 1122 exigeait que la source du masque — statique ou dynamique — soit configurable. Lorsque la découverte était activée, l’hôte retransmettait ses demandes. La première réponse reçue pour l’adresse locale fixait le masque, même si elle était spontanée. Les réponses suivantes étaient ignorées silencieusement.

Ce verrou réduisait les oscillations causées par les duplications ou les retardataires. Il ne créait aucune authentification. Une réponse fausse mais correctement formée pouvait gagner la course contre l’agent prévu.

Le texte conseillait un test de vraisemblance. Le masque ne devait pas être entièrement composé de bits à un, et il devait être nul ou présenter les huit bits de tête activés. Ce filtre éliminait certaines valeurs absurdes, sans pouvoir vérifier l’intention de l’administrateur.

Si les messages Address Mask étaient désactivés, l’hôte n’envoyait aucune demande et ignorait toute réponse. L’effet du paquet dépendait ainsi d’un état local. Comprendre le type ICMP ne suffisait pas à ouvrir la configuration.

Un masque commun n’était pas une preuve commune

L’idée d’un seul masque par LAN expliquait pourquoi les champs de corrélation pouvaient rester inutilisés. Elle n’établissait pas que n’importe quel émetteur connaissait ce masque. La sémantique était collective ; le droit de parler restait restreint.

Un hôte relié à plusieurs LAN devait éventuellement découvrir une valeur pour chacun. Le masque appartenait au couple adresse-interface et à son domaine de diffusion, non à une identité globale de la machine.

Le modèle avait aussi une faiblesse de composition. Le masque arrivait séparément de l’adresse, de la passerelle et des autres données nécessaires au démarrage. Même si chaque protocole répondait correctement, leurs résultats pouvaient appartenir à des contextes ou à des instants différents.

L’avenir de la configuration a consisté en partie à rassembler ces faits, non parce que leur valeur individuelle avait cessé de compter, mais parce que cohérence et provenance devenaient plus faciles à gérer dans une relation commune.

DHCP a d’abord gouverné l’ancien chemin

RFC 2131 décrit le paysage avant sa propre généralisation : RARP pour découvrir une adresse, ICMP pour le masque ou les routeurs, BOOTP pour transporter plusieurs paramètres, et d’autres mécanismes pour d’autres besoins. DHCP a uni allocation d’adresse et configuration dans un échange doté d’états.

Le document ne prétendait pas que la publication de DHCP effaçait aussitôt ICMP. Il mentionnait encore mask request parmi les mécanismes disponibles et classait le masque comme paramètre IP propre à l’interface.

RFC 2132 rend la coexistence concrète. L’option 1 transporte directement quatre octets de Subnet Mask. Lorsqu’un message contient aussi des Router options, le masque doit venir avant elles afin que l’interprétation des adresses repose déjà sur la bonne frontière.

Deux autres options administraient l’héritage. Perform Mask Discovery, code 29, disait au client s’il devait interroger ICMP. Mask Supplier, code 30, disait s’il devait répondre à ces requêtes. Le nouveau canal distribuait donc la valeur et décidait si les anciens rôles de demandeur et de fournisseur restaient actifs.

Ce détail empêche de raconter un remplacement instantané. DHCP offrait une surface de migration : fournir le masque, couper la découverte redondante, ou conserver volontairement une fonction ancienne.

Le nouveau paquet ne supprimait pas la vieille règle d’autorité

Même pendant la coexistence, recevoir un masque par ICMP ne transformait pas l’hôte en agent. En revanche, une configuration DHCP activant Mask Supplier constituait une instruction explicite. La différence ne résidait pas seulement dans la valeur, mais dans le canal qui attribuait le rôle.

En rassemblant adresse, masque et autres paramètres, DHCP réduisait aussi la charge sémantique du silence ICMP. Le serveur qui attribuait ou confirmait l’adresse pouvait livrer simultanément le masque qui l’interprétait.

DHCP ne rendait pas la configuration infaillible. Il remplaçait une question isolée sur un média local par une relation plus large et identifiable, avec des options capables de fermer l’ancien chemin.

La disparition pratique de types 17 et 18 est ainsi moins une victoire d’un format sur un autre qu’un changement d’unité : du fait séparé à la transaction de configuration.

La dépréciation a enregistré un état déjà acquis

RFC 6918 a formellement déprécié plusieurs types ICMPv4. Pour Address Mask Request et Reply, le motif est que des mécanismes tels que DHCP les avaient remplacés pour la configuration des hôtes.

Déprécier ne supprimait ni les numéros ni toute implémentation ancienne. La décision retirait leur pertinence pour de nouvelles dépendances et alignait le registre sur une pratique qui avait déjà changé.

RFC 7279, consacré aux conditions de nouvelles allocations ICMP, conserve les types 17 et 18 dans sa liste avec la mention Deprecated. Leur mémoire demeure afin que d’anciens octets ne soient pas réinterprétés comme un nouveau protocole.

La chronologie comporte donc quatre temps : une découverte locale séparée, une discipline d’autorité plus ferme, une coexistence pilotée par les options DHCP, puis la reconnaissance formelle de la substitution.

Ce que montre réellement une capture

Une réponse de type 18 observée prouve la présence d’un message ICMP portant un masque de 32 bits, avec les adresses, le checksum, l’Identifier et la Sequence visibles au point de capture. Elle peut être rapprochée d’une demande même si l’ancien fonctionnement ne l’exigeait pas.

Elle ne prouve pas que l’émetteur avait été configuré comme agent, que la valeur représentait le plan du réseau, que le destinataire l’a installée, ni qu’une réponse antérieure n’avait pas déjà fermé la fenêtre. La correction syntaxique n’est pas un certificat administratif.

L’absence de réponse prouve encore moins. Elle décrit seulement ce qui n’a pas été vu pendant un intervalle : agent inexistant, panne, filtre ou perte produisent la même trace. Le masque de repli révèle la règle de l’hôte, pas la topologie certaine du LAN.

Le mécanisme historique a donc distribué des affirmations bornées. Une réponse locale pouvait guider le forwarding ; un silence pouvait déclencher une supposition réversible ; aucun des deux ne suffisait à créer le pouvoir de configurer les autres.

Sources et limites de preuve

Le corpus fermé comprend RFC 950, RFC 1122, RFC 2131, RFC 2132, RFC 6918 et RFC 7279. Il établit le dessin, les exigences d’hôte, la coexistence DHCP et la dépréciation. Il ne mesure aucun déploiement, n’authentifie aucun émetteur capturé, ne contrôle aucun produit et ne prouve pas qu’un masque effectivement installé était exact.