Résumé

  • RFC 1335 proposait que chaque hôte conserve une adresse permanente, valable dans son réseau, et obtienne temporairement une adresse externe globalement unique auprès d’un External Address Sharing Service (EASS).
  • Ce texte informatif, présenté comme une « idée », n’est pas un compte rendu de déploiement : les sources disponibles ne prouvent ni sa mise en œuvre par des opérateurs ni la résolution de l’épuisement d’IPv4.

On imagine souvent l’adresse Internet comme une étiquette attachée à une machine. RFC 1335 demande si cette étiquette doit être mondiale en permanence. Sa réponse, formulée alors que l’espace d’adresses de 32 bits suscitait des inquiétudes au début des années 1990, consiste à distinguer l’adresse utile à l’intérieur d’un réseau de celle, plus rare, nécessaire pour communiquer au-delà.

Le mémo précise lui-même son statut. Daté de mai 1992, il se dit informatif, ne définit aucune norme Internet, se présente comme un texte d’« idée » et invite à la discussion. C’est essentiel : il témoigne de ce qu’une proposition jugeait possible, pas d’un service effectivement exploité. RFC 1335

La pression décrite vient du système d’allocation par classes tel que le mémo le présente. Son tableau, daté d’avril 1992, dénombre 7 006 réseaux de classe B alloués sur 16 383 et avertit que cet espace pourrait bientôt s’épuiser si la croissance se poursuivait. La classe C offrait bien davantage de numéros de réseau, mais seulement 254 numéros d’hôte par réseau, jugés trop peu nombreux pour la plupart d’entre eux. Ce sont les chiffres et prévisions du document à l’époque, non une mesure rétrospective de la date réelle de l’épuisement.

RFC 1335 compare sa proposition aux pistes alors débattues. Le supernetting et ce qu’il nomme C-sharp réorganiseraient les allocations de classe C, mais, selon le mémo, exigeraient des changements au routage extérieur et une coordination potentiellement mondiale. D’autres approches réutiliseraient le champ de 32 bits avec une autre signification et une réécriture aux frontières, au prix, selon les auteurs, de changements importants dans les passerelles et le routage. Il s’agit de leur caractérisation des alternatives, pas d’une évaluation neutre de chacune.

Le Dual Network Addressing (DNA) répartit les fonctions entre deux adresses. Chaque machine conserverait une adresse interne, unique au sein de son réseau, comme adresse permanente locale. Le réseau disposerait aussi d’un pool limité d’adresses externes globalement uniques. Lorsqu’un hôte voudrait joindre un autre réseau, il demanderait une adresse externe temporaire à l’External Address Sharing Service de son réseau, puis pourrait la rendre. L’EASS serait ainsi un point d’allocation administratif et technique entre usage local et portée globale — sans que l’adresse authentifie une personne, un hôte ou une transaction.

La politique ne se résume pas à « tout le monde partage ». RFC 1335 distingue trois catégories : les machines ayant fréquemment besoin de communications entrantes et sortantes pourraient recevoir une adresse externe permanente ; celles auxquelles toute communication vers l’extérieur est interdite n’en recevraient aucune ; les autres partageraient des adresses temporaires pour des communications initiées depuis l’intérieur, sans être joignables depuis l’extérieur dans le modèle décrit. L’allocation devient donc une question de politique d’exploitation autant que de format de paquet.

Pour fonctionner, la proposition nécessiterait des changements logiciels sur les hôtes, afin de prendre en charge deux interfaces ou adresses IP logiques sur une interface physique. Le mémo envisage également un DNS sensible à la source : un serveur de noms pourrait répondre par une adresse interne ou externe selon l’origine de la requête. Il suggère que DHCP puisse remplir le rôle d’EASS. Cette suggestion n’établit ni que DHCP a déployé DNA ni que les deux mécanismes appartiennent à une même filiation.

La promesse d’une adoption par étapes constitue son aspect de gouvernance le plus intéressant. RFC 1335 soutient que chaque réseau pourrait adopter DNA à son propre rythme, sans changer les algorithmes de routage extérieur ni affecter les réseaux qui ne l’adopteraient pas. L’intervention proposée se déplace donc de la coordination mondiale du routage vers les pools locaux, les logiciels des hôtes et les règles du réseau. Pourtant, le document ne fournit aucun dossier de déploiement, test d’interopérabilité, observation du trafic ou décompte d’adoption permettant de vérifier cette promesse.

Les textes ultérieurs fixent des repères, pas une succession démontrée. Les RFC 1518 et 1519 ont établi CIDR comme stratégie normalisée d’allocation des adresses et d’agrégation des routes ; CIDR agit à l’échelle des préfixes et du routage, contrairement aux adresses internes et au pool temporaire de DNA. RFC 1531 a ensuite spécifié DHCP comme cadre de configuration incluant l’attribution réutilisable d’adresses, sans prouver qu’EASS fut mis en œuvre. RFC 1631 décrit la traduction d’adresses à une frontière réseau : comparaison limitée, et non preuve que DNA a causé NAT. Enfin, RFC 1752 consigne une recommandation d’IPng acceptée par l’IESG, décision institutionnelle distincte du texte ouvert de 1992. RFC 1287 · RFC 1518 · RFC 1519 · RFC 1531 · RFC 1631 · RFC 1752

RFC 1335 fournit ainsi aux historiens une séparation nette entre proposition et résultat. La pénurie d’adresses pouvait être abordée en changeant qui reçoit un numéro mondialement unique, pour combien de temps et sous quelle politique locale — et pas seulement en agrandissant ou réorganisant le système mondial de routage. Le texte ne démontre pas que le dispositif a été déployé, qu’il était sûr ou interopérable, ni qu’il a réussi. Il précise même que les questions de sécurité ne sont pas traitées.

Une adresse temporaire peut servir à l’allocation ; elle n’est ni une identité, ni une autorisation, ni une preuve d’accessibilité ou d’échange applicatif abouti.