Résumé

  • Avant de proposer quatre mécanismes facultatifs, le RFC 1888 conseillait de redessiner nativement en IPv6 les plans d’adressage OSI existants.
  • La réversibilité ne réglait pas trois écarts : une zone OSI pouvait couvrir plusieurs liens, les préfixes hétérogènes s’agrégeaient mal et une identité NSAP d’hôte ne désignait pas une interface IPv6.
  • Le RFC 4048 a ensuite dissocié des mécanismes apparemment inutilisés de deux erreurs dans le sens inverse ; le RFC 4548 n’a corrigé que ce fragment de registre.

Ce que la réversibilité ne rendait pas

Publié comme document expérimental en août 1996, le RFC 1888 ne prétendait pas établir une norme Internet. Il commençait même par une recommandation plus radicale que ses formules : une organisation disposant d’un plan NSAP prévu ou déployé devait concevoir un plan IPv6 natif et y reporter sa topologie locale lorsque cela était possible.

Cette priorité venait de trois incompatibilités. Dans la hiérarchie OSI/IS-IS, une même zone pouvait englober plusieurs liens physiques. Le sous-réseau IPv6 supposait au contraire un lien unique. Réutiliser le numéro de zone comme numéro de sous-réseau créait donc une égalité de notation, non une égalité de voisinage.

Le deuxième coût concernait l’agrégation. Deux populations d’adresses ne se résument en une annonce que si elles partagent un préfixe pertinent. Les adresses IPv6 normales et les NSAPA restreintes remappées ne formaient pas spontanément cet ensemble. Une fonction pouvait reconstruire chaque entrée à l’identique tout en alourdissant la table globale.

Enfin, plusieurs NSAP pouvaient identifier un système OSI dans son ensemble, par-delà ses interfaces. En IPv6, l’adresse appartient à l’interface. La conversion ne décidait donc pas par quel lien joindre la machine. Le RFC excluait aussi de son périmètre la migration des protocoles et infrastructures ES-IS et IS-IS : il transportait un nom numérique, pas le plan de contrôle qui l’avait rendu routable.

Quatre compromis, et aucun certificat d’usage

Le premier mécanisme rangeait une NSAPA ICD ou DCC restreinte dans seize octets IPv6 précédés par 0x02. Sur le sous-ensemble admis, la transformation était algorithmique et inversible. Le texte avertissait pourtant que le routage serait inefficace et qu’une zone répartie sur plusieurs sous-réseaux physiques exigerait un dispositif supplémentaire.

Le deuxième, marqué 0x03, tronquait la NSAPA. La partie conservée pouvait guider le paquet vers une zone, mais il fallait encore joindre la NSAPA complète dans une option de destination ou transporter un paquet CLNP encapsulé. Le destinataire devait alors choisir localement entre transmettre, décapsuler et rejeter. La découverte automatique du dernier saut restait hors spécification ; une table statique ou un mécanisme futur analogue à ES-IS n’était qu’une piste.

La perte d’identité touchait aussi les diagnostics. L’autoconfiguration ordinaire ne fonctionnait pas sans adaptation, une NSAPA complète ne tenait pas dans un en-tête de routage IPv6 et une erreur ICMP renvoyée vers une source tronquée pouvait être abandonnée. Ainsi, la compatibilité pouvait masquer l’échec tout en supprimant son reçu.

Le troisième mécanisme conservait une adresse IPv6 ordinaire et ajoutait une option portant la NSAPA source ou destination complète. Un nœud qui n’utilisait pas cette fonction n’était pas tenu de l’implémenter. Voir l’option prouvait donc son émission, nullement sa compréhension ou son activation à l’arrivée.

Le quatrième sens plaçait IPv6 dans une NSAPA de vingt octets, sous l’AFI 35 attribué par l’IANA et l’ICP zéro. Le texte interdisait les inclusions récursives susceptibles de provoquer des anomalies ou des boucles, déjà discutées dans le RFC 1326. Le RFC 1629 fournit le contexte NSAP sur ATM et le RFC 3513 celui de l’architecture IPv6 ultérieure ; aucun ne démontre un déploiement du RFC 1888.

Une retraite en deux diagnostics

En 2005, le RFC 4048 a formulé une appréciation prudente : autant que l’IETF le savait, les conversions NSAP dans IPv6 n’avaient jamais été sérieusement utilisées et n’étaient pas prises en charge par les implémentations IPv6. Il s’agit d’un constat institutionnel attribué, pas d’un recensement universel. Il a néanmoins conduit au classement historique et au retour du préfixe concerné à l’état réservé.

Le sens inverse méritait un traitement différent, car il suscitait encore un intérêt, notamment pour ATM. Deux erreurs affectaient la section 6. L’ICP occupait seize bits, donc deux octets, et non le seul troisième octet. L’IDI composé de quatre chiffres décimaux devait être codé sur deux octets en décimal codé binaire, et non comme une valeur binaire libre.

Le RFC 4548 a remplacé cette seule section en 2006. Sous l’AFI 35, l’ICP décimal zéro désigne le format IPv6 et un le format IPv4 ; les valeurs 2 à 9999 exigent un format défini et publié ainsi qu’un consensus IETF. Le registre IANA des numéros OSI NSAPA conserve aujourd’hui ces significations. Il atteste une autorité de nommage, pas l’existence d’un logiciel, d’une route ou d’un trafic.

Les pages d’information du RFC Editor pour les RFC 1888, 4048 et 4548 rendent visibles les statuts et les relations de remplacement. Elles montrent surtout une discipline : retirer les mécanismes apparemment sans usage, corriger le fragment encore utile et ne pas confondre cette correction avec la résurrection de l’ensemble.