Résumé

  • La RFC 1219 plaçait les bits de sous-réseau à gauche et les bits d’hôte à droite, avec une réserve centrale. Le comptage « en miroir » permettait à chaque population de grandir sans modifier les adresses déjà attribuées.
  • Le gain portait sur la renumérotation, non sur toute reconfiguration : un bit de croissance consommé pouvait imposer un nouveau masque et un protocole de routage interne capable d’en gérer plusieurs.
  • Lors d’un déploiement incomplet, un masque trop long envoyait parfois un voisin local vers la passerelle ; un masque trop court faisait chercher par ARP une destination distante. Une adresse inchangée pouvait donc recouvrir deux erreurs opposées.

La réserve se trouvait au milieu

La RFC 1219, On the Assignment of Subnet Numbers, porte la date d’avril 1991 et le nom de P. F. Tsuchiya. Le registre du RFC Editor la classe « Informational ». Le texte précise que la méthode relève d’un choix local et discrétionnaire, et non d’une norme Internet ; la fiche IETF atteste le document, pas son déploiement.

Le point de départ est le masque défini dans la RFC 950. Dans la partie locale d’une adresse, elle recommandait une suite contiguë de bits de sous-réseau du côté le plus significatif. L’entreprise qui ne savait pas si elle aurait surtout besoin de nouveaux sous-réseaux ou de davantage de machines dans chacun devait pourtant réserver de l’espace avant de connaître la réponse.

RFC 1219 évite ce pari. Les numéros d’hôte progressent normalement depuis les bits de poids faible. Les numéros de sous-réseau avancent en sens miroir depuis les bits de poids fort. Les uns et les autres encadrent des g-bits initialement nuls, disponibles pour la croissance.

Un sous-réseau qui gagne des hôtes prend un bit du côté hôte. Une organisation qui crée un sous-réseau le prend du côté sous-réseau. La chaîne binaire déjà attribuée aux machines peut demeurer identique. C’est une économie importante : pas de nouvelle adresse à propager dans tous les fichiers, noms ou dépendances.

Mais la stabilité du numéro ne dit pas où passe désormais la limite entre sous-réseau et hôte. Cette information appartient au masque.

Le masque était l’état actif de l’accord

Lorsque la racine transforme un g-bit en s-bit, un sous-réseau existant peut devoir ajouter un « 1 » à son masque. Lorsque l’autorité locale transforme un g-bit en h-bit pour accueillir plus d’hôtes, toutes les machines du sous-réseau peuvent devoir raccourcir le leur. L’adresse ne change pas ; sa lecture, oui.

La RFC 1009 fournit le contexte des passerelles. Elle admettait plusieurs masques dans un même réseau subnetté et exigeait qu’un masque distinct puisse être configuré sur chaque interface de passerelle. RFC 1219 ajoute donc une condition : le protocole de routage interne doit savoir traiter plusieurs masques.

Cette aptitude ne démontre aucun état réel. Un équipement peut posséder la fonction sans recevoir la nouvelle valeur. Une annonce peut partir sans être installée partout. Une base d’allocation peut être exacte alors que l’interface reste ancienne. Pour conclure, il faut des traces différentes : calcul d’allocation, configuration effective, table de routage convergée, paquets livrés, puis service observé.

Le dernier bit supprimait l’autonomie

Le schéma répartit aussi le pouvoir. Une autorité racine, RootAA, attribue les sous-réseaux. Chaque autorité de sous-réseau distribue ses numéros d’hôte. Tant qu’il existe plusieurs g-bits, les deux côtés peuvent généralement avancer séparément, chacun depuis son extrémité.

Le dernier bit disponible change la nature de la décision. S’il devient un s-bit, il ouvre de l’espace aux sous-réseaux et ferme cette capacité aux hôtes. S’il devient un h-bit, l’inverse se produit. Les deux autorités doivent alors coordonner leur choix.

Ce passage est moins un détail binaire qu’un problème de gouvernance. La racine connaît la pression globale ; l’autorité locale connaît la saturation d’un segment. Deux registres cohérents pris isolément peuvent se contredire si leur version ou leur calendrier diverge. La conservation des adresses ne tranche pas le conflit.

Il faut également respecter la frontière de preuve. RootAA et les autorités locales sont les rôles du modèle. La RFC ne prouve pas qu’un opérateur identifié les a institués, qu’une décision a été approuvée ou que les configurations ont été diffusées.

Une erreur faisait un détour, l’autre une impasse

L’intérêt opérationnel du texte apparaît dans son analyse des masques périmés.

Avec trop de bits à « 1 », une machine croit qu’une partie de son véritable sous-réseau se trouve à l’extérieur. Elle remet donc le paquet à une passerelle. Celle-ci peut le renvoyer sur le même segment et éventuellement produire un ICMP Redirect. Le paquet peut arriver, mais au prix d’un détour. La possibilité du redirect ne prouve ni son émission, ni son acceptation, ni sa capacité à réparer durablement le chemin.

Avec trop peu de bits à « 1 », la machine classe une destination réellement distante comme locale. Elle lance une requête ARP sur le lien au lieu d’utiliser la passerelle. La destination distante ne peut pas répondre à cette diffusion locale. Ici, aucun détour de secours : la communication peut simplement échouer. Des masques incohérents peuvent aussi perturber les diffusions.

Ainsi, deux postes gardent exactement leur ancienne adresse et vivent des réalités incompatibles. L’un atteint son voisin par un chemin inutilement long ; l’autre n’atteint pas une machine distante. Un indicateur « zéro adresse modifiée » ne voit ni l’un ni l’autre.

Les exemples prouvent les conséquences prévues par l’algorithme, pas l’issue d’une migration réelle. Ils ne prouvent pas qu’une application est restée disponible ou qu’un réseau particulier a convergé.

Ce qui reste du mécanisme

RFC 1219 observait que la méthode était peu connue et encore moins implémentée au moment de la publication. Cette remarque borne 1991 ; elle ne mesure pas une adoption ultérieure. Le dossier ne contient ni version de logiciel, ni rapport d’opérateur, ni capture de trafic permettant d’écrire une histoire du déploiement.

La sécurité est hors champ : le document dit ne pas en discuter. On ne peut donc en tirer aucune propriété d’authentification, d’autorisation, d’intégrité ou de retour arrière sûr.

Son apport historique est plus précis. Une identité stable peut masquer un changement du système qui l’interprète. L’inventaire conserve l’adresse. L’hôte applique le masque. Le routage décide du chemin. Le paquet prouve la joignabilité. L’utilisateur juge le résultat. Ne confondre aucun de ces registres est la vraie discipline laissée par RFC 1219.

Sources