Résumé

  • RFC 1918 autorise chaque entreprise à réutiliser trois blocs IPv4 sans coordination avec un registre ; l’adresse n’est unique que dans l’entreprise ou le groupe qui partage volontairement ce plan.
  • La fusion n’établit pas qu’un ancien plan était fautif. Elle agrandit le domaine où l’unicité doit être assurée et transforme deux usages locaux légitimes en une ambiguïté commune.
  • Routage, DNS, renumérotation, traduction et authentification répondent à des questions différentes. Un paquet reçu ne prouve pas à lui seul que le bon hôte a été atteint.

Deux plans exacts, une vue impossible

Le cas le plus simple ne comporte ni fraude ni panne initiale. Dans la société A, une adresse de 10/8 désigne un serveur de gestion. Dans la société B, elle désigne une imprimante ou un équipement d’atelier. Les deux équipes ont construit leur réseau dans un espace explicitement réutilisable. Les deux tables de routage sont cohérentes tant qu’elles restent dans leur domaine.

L’interconnexion change la question. Elle ne demande plus « où se trouve cette adresse dans A ? » ou « où se trouve-t-elle dans B ? », mais « où se trouve cette adresse dans le nouvel ensemble ? ». Le nombre n’a perdu aucun bit. C’est le contexte qui le rendait univoque qui a disparu.

Cette scène éclaire mieux RFC 1918 qu’un inventaire des plages. Le document a organisé une économie de coordination : ne pas payer le coût mondial de l’unicité pour des machines qui n’en ont pas besoin, en acceptant de payer plus tard si le périmètre de communication s’élargit.

Le désaccord de 1994 portait déjà sur l’avenir

RFC 1597, publié en mars 1994, proposait de distinguer les hôtes selon leurs besoins de connectivité. Beaucoup d’équipements internes pouvaient fonctionner avec des numéros non ambigus dans une seule entreprise. La réservation de blocs réutilisables évitait de mobiliser une adresse mondiale pour chaque caisse, poste administratif ou interface interne.

En juillet, RFC 1627 contesta cette rupture avec l’unicité globale. Ses auteurs ne niaient pas l’utilité immédiate d’un réseau privé ; ils attaquaient la prévision implicite. Une machine jugée interne peut devenir accessible demain. Deux sociétés peuvent collaborer ou fusionner. Une licence, un service connu ou une configuration peut s’attacher au numéro. Le texte cite notamment une renumérotation chez Apple, mais le dossier de sources présent ne permet pas d’en confirmer indépendamment le volume ni le coût.

Ce désaccord n’est pas une note de bas de page extérieure à la décision finale. Eliot Lear figure parmi les auteurs de RFC 1627 puis de RFC 1918. En février 1996, le nouveau document, devenu BCP 5, rendit obsolètes le projet initial et sa critique. Il conserva pourtant le risque central signalé par les opposants. La meilleure pratique accepta la réutilisation tout en reconnaissant que l’unification de réseaux privés pouvait imposer une renumérotation.

« Privé » décrit une portée, pas un propriétaire

Les trois blocs sont 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16. Une entreprise peut y puiser sans consulter IANA ni un registre Internet. Plusieurs entreprises peuvent choisir le même sous-ensemble. L’unicité promise est donc expressément locale : elle vaut dans une entreprise, ou dans un ensemble d’entreprises qui coordonnent leur usage parce qu’elles souhaitent communiquer.

Le registre spécial d’IANA classe encore ces trois plages comme Private-Use et non globalement joignables. Cela ne confère pas un titre à la première organisation qui les emploie. Si A et B choisissent 10.1.1.0/24, aucun mécanisme de RFC 1918 ne rend A prioritaire. Le texte organise précisément la coexistence d’usages sans coordination mondiale.

La cohérence dépend alors de barrières concordantes. RFC 1918 demande de ne pas propager les routes privées sur les liaisons interentreprises, de ne pas y transférer les paquets portant ces adresses et de contenir les références indirectes, notamment DNS. Le plan d’adressage, la portée des routes et la visibilité des noms doivent décrire le même monde.

Le document ne transforme pas cette séparation en garantie de sécurité. Sa section consacrée à la sécurité dit que ces questions ne sont pas traitées. Un hôte non routé depuis l’Internet peut être moins exposé dans une topologie donnée ; son adresse ne devient pas pour autant une preuve d’identité ou une politique d’accès.

La clause de fusion rend le coût explicite

RFC 1918 avertit que plusieurs internets privés, administrés sans coordination puis réunis, peuvent contenir des adresses dupliquées. Les hôtes concernés devront alors changer de numéro. Il décrit aussi le cas de deux organisations qui décident ultérieurement d’établir une connectivité IP. Choisir aléatoirement les sous-blocs peut diminuer le risque, pas délivrer un certificat d’absence de collision.

La renumérotation elle-même touche davantage qu’une interface. Le RFC cite les entrées DNS et les fichiers de configuration d’autres hôtes qui font référence à l’ancienne adresse. DHCP peut réduire une partie du travail. Il ne décide pas quelle application représente une identité durable, qui peut supporter une interruption ni quelle organisation doit changer en premier.

Le conflit ne se résout donc pas par un procès de légitimité. Les deux plans pouvaient respecter la règle applicable avant la fusion. La nouvelle direction doit choisir une architecture : maintenir des domaines séparés, traduire entre eux, utiliser des mandataires applicatifs, déplacer certains services ou renuméroter un périmètre. Chaque option possède son propre coût et son propre détenteur de commande.

Le « realm » donne un nom au contexte perdu

RFC 2663 formalisa plus tard la notion d’address realm : un domaine réseau dans lequel les adresses sont attribuées de manière unique et où le routage sait atteindre les entités correspondantes. Cette définition ajoute mentalement ce que l’adresse privée ne contient pas. Le couple utile n’est plus seulement le numéro, mais le numéro dans un domaine donné.

La traduction traditionnelle relie un domaine privé à un espace externe en modifiant une représentation. Elle suppose toutefois que les espaces ne se recouvrent pas. Si une adresse désigne déjà un hôte des deux côtés, RFC 2663 décrit la twice NAT, qui peut traduire simultanément source et destination. L’existence même de ce mécanisme montre que la route seule ne peut choisir entre deux sens identiques.

RFC 3022 détaille ensuite la NAT traditionnelle. Basic NAT associe des groupes d’adresses ; NAPT associe également des ports. Les flux aller et retour doivent rencontrer un état compatible. Cette centralisation peut masquer une modification de topologie aux hôtes, mais elle retire à l’adresse sa signification de bout en bout et installe davantage d’état dans le réseau.

La traduction est donc un registre opérationnel de correspondances, non une restauration magique de l’unicité. Pour expliquer un événement, il faut conserver l’adresse interne, sa portée, sa représentation externe, l’instant, le protocole et le dispositif qui détenait l’état.

La mauvaise machine peut répondre correctement

RFC 5684, publication indépendante et non spécification IETF sur la voie des normes, étudie ensuite des topologies où des espaces privés se recouvrent derrière plusieurs NAT ou entre un accès distant et un VPN d’entreprise. Son apport le plus net est la « mistaken end host identity » : une requête destinée à un résolveur amont peut être livrée à un hôte local portant le même numéro ; un service local peut être confondu avec le service d’entreprise attendu.

Ce n’est pas toujours une panne visible. Une connexion peut réussir vers le mauvais interlocuteur. Le document recommande, pour ses scénarios précis, des adresses non chevauchantes ou mondiales pour certains services critiques et une authentification de bout en bout plutôt qu’une confiance fondée sur l’adresse source.

Il faut dès lors séparer les preuves. La configuration prouve quel numéro une machine portait dans son domaine. La route prouve une décision de transfert. La table de traduction prouve une correspondance. Le certificat ou le protocole d’authentification peut prouver un pair. Le résultat applicatif prouve qu'un service attendu a fonctionné. Une lumière verte à une couche ne signe pas les autres reçus.

100.64/10 n’est pas une quatrième plage RFC 1918

RFC 6598 créa en 2012 un espace partagé, 100.64.0.0/10, pour les liaisons entre CGN de fournisseur et équipements clients. Il le distingue expressément de l’espace privé d’entreprise de RFC 1918. Le registre IANA place les deux familles parmi les usages spéciaux non globalement joignables, mais leurs autorités opérationnelles et leurs limites ne sont pas les mêmes.

Cette précision ferme le raisonnement. Il n’existe pas un unique intérieur indifférencié face à l’Internet. Un foyer, une entreprise et un réseau de fournisseur sont des domaines distincts. Une adresse réutilisée reste intelligible tant que le système transporte avec elle la bonne portée. RFC 1918 n’a pas supprimé l’unicité ; il a choisi l’endroit où elle devait être tenue. Une fusion déplace cet endroit. La réussite du projet dépend alors de la capacité à déplacer aussi les routes, les noms, les cartes de traduction et les preuves d’identité.

Sources