Résumé

  • RFC 1681 proposait d’encoder dans l’adresse de destination la catégorie du payeur, ou un index vers une table de tarification, afin que clients et routeurs de bordure puissent décider avant tout contact.
  • Le texte refusait que l’usager découvre le coût après coup et montrait pourquoi un avertissement à la connexion échouait lorsque le logiciel ne prévoyait aucune interaction humaine ou suivait une redirection Gopher.
  • Une adresse pouvait sélectionner une politique ; elle ne prouvait à elle seule ni la personne engagée, ni les conditions en vigueur, ni son accord, ni la prestation, ni le comptage, ni la validité de la facture ou du paiement.

Une redirection sans guichet de consentement

Dans RFC 1681, le passage le plus concret sur la facturation tient en quelques lignes. Un serveur Gopher pourrait rediriger son visiteur vers une adresse « pay-to-play » sans afficher l’avertissement nécessaire. Il ne s’agit pas du récit d’une fraude observée. C’est un scénario de menace destiné à tester l’ordre des opérations.

L’auteur en tire une conclusion exigeante : un message affiché au moment de la connexion ne suffit pas. De nombreuses interactions réseau n’offrent aucun point d’arrêt où demander à une personne si elle accepte de payer. Le programme peut avoir choisi le nouveau destinataire et engagé la communication avant que l’usager ne voie quoi que ce soit.

L’idée était donc de déplacer une information commerciale vers l’amont. Certains bits de l’adresse indiqueraient qui paie. Un champ plus large pourrait désigner une entrée dans une table d’algorithmes tarifaires. À la frontière d’une organisation, le routeur reconnaîtrait la classe et appliquerait sa politique locale avant de laisser passer le trafic.

L’adresse n’aurait pas contenu la facture. Elle aurait fourni un signal précoce, lisible par les machines, suffisamment près de la décision de routage pour permettre un refus avant contact.

Le nombre de machines ne suffisait plus à compter les adresses

La facturation n’était qu’un cas dans une réflexion plus large. La plupart des hôtes terminaux de l’époque n’avaient qu’une adresse, et les projections d’espace d’adressage se fondaient volontiers sur le nombre de machines. RFC 1681 avertissait que cette hypothèse pouvait devenir une erreur sérieuse.

Une adresse secondaire pouvait représenter un service plutôt que la machine qui l’hébergeait ce jour-là. Le service serait déplacé sans modifier son identité extérieure. Plusieurs adresses sur un même hôte pouvaient également offrir des vues ou des politiques d’accès distinctes, sans imposer un nouveau protocole ou un port inhabituel aux utilisateurs. Un pare-feu aurait pu ouvrir l’adresse consacrée au service tout en fermant les autres, à condition que les processus soient correctement liés à chacune d’elles.

Le document envisageait une autre solution : étendre DNS pour renvoyer aussi un numéro de port. Son coût supposé était celui du parc installé, car chaque client concerné aurait dû être modifié. Charger l’adresse d’une nouvelle signification semblait éviter cette migration applicative.

Mais le gain déplaçait la complexité. Une même adresse pouvait devenir localisateur d’hôte, identité de service, classe d’accès, identifiant de session utilisateur, point d’ancrage de mobilité et catégorie tarifaire. Ces fonctions n’avaient ni la même durée, ni le même responsable. Le service pouvait survivre à une machine ; la session se terminait à la déconnexion ; la table tarifaire changeait sans que les bits de destination changent. Conserver l’identifiant ne suffisait donc pas à conserver son interprétation historique.

Quatre façons de répartir le coût

RFC 1681 distinguait quatre schémas possibles de tarification à l’usage. Dans le modèle ordinaire, chaque hôte payait ses propres paquets, ce qui pouvait faire payer les deux interlocuteurs. Le modèle « caller pays » attribuait la dépense à l’appelant. L’appel en PCV la transférait au destinataire. Enfin, l’équivalent d’un numéro américain « 900 » faisait payer à l’appelant un supplément au profit du serveur.

Cette diversité rendait indispensable de savoir à l’avance qui paierait. Apprendre seulement après la communication qu’un coût avait été engagé était jugé inacceptable.

Savoir qui paie ne définit toutefois pas le tarif. RFC 1125 avait séparé l’unité de compte, la base de calcul, le montant, la partie débitée ou créditée, le compteur de paquets retenu et les plafonds. Un bit « appelant » correctement lu ne dit pas si l’on facture au kilo-octet, au paquet ou à la session. Il ne choisit pas le compteur faisant foi, ne révèle pas le plafond autorisé et ne règle pas un désaccord.

L’extension proposée par RFC 1681 — utiliser l’adresse comme index d’une table — rend cette dépendance explicite. Si les bits pointent vers une ligne, la règle réelle se trouve dans cette ligne, sous une version, un exploitant et une période de validité précis. Une archive qui garde l’adresse mais perd la table conserve la clé et détruit la signification.

La bordure pouvait refuser, pas consentir à la place de l’usager

Le routeur de bordure représentait une surface de contrôle limitée et vérifiable. RFC 1681 imaginait, par exemple, que des postes anonymes dans une salle informatique de résidence universitaire ne puissent pas passer d’appels en PCV. L’organisation pouvait refuser localement une classe de destination avant que son réseau n’engage la transaction.

Une autorisation de passage ne valait pas accord humain. Le poste pouvait être partagé, la requête automatisée, le titulaire du compte distinct de l’opérateur de la session, et son mandat plafonné. La table du service distant pouvait aussi différer de celle que le routeur avait consultée. La décision réseau pouvait être conforme à sa politique tout en laissant la dette contestable.

Le texte proposait également une adresse IP par utilisateur pendant sa session. Les routeurs continueraient à collecter leurs mesures par adresse ; l’hôte conserverait la correspondance entre adresse et connexion ; la facturation serait effectuée ensuite, hors ligne. Des formes d’adresses différentes pourraient ouvrir ou fermer l’accès aux services coûteux selon la classe de l’utilisateur.

Le dispositif améliorait la possibilité de joindre des traces. Il ne transformait pas l’adresse en identité personnelle. Pour attribuer un usage, il faudrait la mesure du routeur, le journal horodaté des affectations de l’hôte, l’authentification, le mandat de dépense, la table applicable et les traces du fournisseur. Même une adresse temporairement individuelle ne prouve pas qui tenait la session au moment décisif.

Un document publié n’était pas une architecture de paiement déployée

La fiche RFC Editor classe RFC 1681 comme Informational. Le document répondait à l’appel à contributions IPng de RFC 1550 et précisait que sa publication ne signifiait pas que l’aire IPng acceptait ses idées. RFC 1550 présentait ces textes comme des matériaux pour le processus de sélection et comme des éléments de son histoire.

Il est donc trompeur d’utiliser l’avenir pour valider rétroactivement la proposition. Oui, les interfaces IPv6 peuvent avoir plusieurs adresses : RFC 4291 affecte les adresses aux interfaces et autorise plusieurs types et portées sur une même interface. Cela ne démontre ni l’adoption de bits tarifaires, ni une filiation causale avec RFC 1681.

La localisation de services a, elle aussi, reçu un mécanisme explicite. RFC 2782 définit l’enregistrement SRV avec service, protocole, priorité, poids, port et cible, sous le contrôle des spécifications applicatives. Il aide à trouver un service ; il ne porte ni prix, ni payeur, ni consentement, ni compteur, ni facture.

La recommandation de réserver 2^6, voire 2^8, adresses supplémentaires par hôte était une marge de planification pour plusieurs usages possibles, notamment le coûteux modèle d’une adresse par utilisateur. Ce n’était ni une moyenne observée, ni un droit alloué.

La preuve devait traverser toute la chaîne

Un système responsable aurait dû conserver séparément la destination choisie, la classe ou l’index tarifaire, la version de la table et son responsable, la décision de la bordure, le principal authentifié, les conditions montrées avant engagement, l’acceptation du service et la prestation utile, l’unité mesurée et son compteur, le calcul de la facture et ses limites, puis le règlement, l’annulation ou le litige.

Aucun échelon ne fait foi pour le suivant. Reconnaître une classe ne prouve pas l’actualité de la table. Laisser passer un paquet ne prouve pas le consentement. Établir une connexion ne prouve pas le service. Compter des octets ne prouve pas le prix unitaire. Émettre une facture ne prouve pas qu’elle a été payée.

La primauté du code en fonctionnement formulée par Heng Lu impose de ne pas confondre proposition, publication, adoption et état observé. La spécification initiale minimale demande de distinguer les règles communes indispensables des arrangements commerciaux qui peuvent rester locaux. La réalité plutôt que le plaidoyer fixe enfin la limite éditoriale : ni relancer ce mécanisme, ni le tourner en dérision, mais décrire exactement sa portée.

RFC 1681 voulait qu’un réseau voie une règle avant de dépenser l’argent de quelqu’un. Sa leçon durable n’est pas que le prix aurait dû devenir une propriété de l’adresse. Elle tient à l’ordre des preuves : un signal précoce ne protège l’usager que si l’identité, l’autorisation, la livraison, la mesure et le règlement restent chacun vérifiables.

Sources