Zusammenfassung

  • RFC 1681 schlug vor, eine Zahlerklasse oder den Index einer Abrechnungstabelle in der Zieladresse zu codieren, damit Clients und Grenzrouter vor dem Kontakt entscheiden konnten.
  • Das Papier lehnte eine nachträgliche Kostenüberraschung ab und zeigte, warum eine Meldung beim Verbindungsaufbau in automatisierten Abläufen oder nach einer stillen Gopher-Weiterleitung nicht genügte.
  • Die Adresse konnte eine Regel auswählen, aber weder die handelnde Person noch aktuelle Bedingungen, Einwilligung, nutzbare Leistung, korrekte Messung, berechtigte Rechnung oder Zahlung allein beweisen.

Eine Warnung nach der Weiterleitung war keine Vorwarnung

Der stärkste Einzelfall in RFC 1681 ist eine gedachte Gopher-Weiterleitung. Ein Server könnte den Aufrufer an eine kostenpflichtige Adresse schicken, ohne die erforderliche Warnung anzuzeigen. Das Dokument berichtet keinen realen Gopher-Betrug. Es prüft eine Systemgrenze: Kann Software eine wirtschaftlich folgenreiche Entscheidung treffen, bevor der Mensch überhaupt eine Entscheidungsmöglichkeit erhält?

Eine Nachricht beim Verbindungsaufbau reichte nach Auffassung des Autors nicht. Viele Netzwerkinteraktionen hatten keinen Eingriffspunkt für eine Nutzerabfrage. Wenn der Hinweis erst mit dem Kontakt erschien, konnte das abrechenbare Ereignis bereits begonnen haben.

Bellovin wollte daher einen Teil der kommerziellen Bedeutung vorziehen. Einige Bits der Zieladresse sollten bestimmen, wer zahlt. Ein größeres Feld konnte als Index einer Tabelle von Abrechnungsalgorithmen dienen. Ein organisatorischer Grenzrouter konnte die Klasse erkennen und seine lokale Regel anwenden, bevor er das Paket weiterleitete.

Die Adresse war damit kein Kleinstvertrag. Sie war ein maschinenlesbarer Selektor an einer Stelle, an der Ablehnung noch vor Kontakt möglich war.

Eine Maschine konnte viele Adressbedeutungen brauchen

Die Abrechnung war Teil einer breiteren Kapazitätsfrage. Die meisten Endsysteme galten 1994 als einadressig, und Bedarfsrechnungen zählten häufig Hosts. RFC 1681 warnte, dass diese Annahme ernsthaft danebenliegen konnte, wenn ein Rechner getrennte Adressen für Dienste, Zugriffsansichten, Nutzer oder begrenzte Mobilität verwendete.

Eine sekundäre Adresse konnte einen Dienst statt der gerade ausführenden Maschine bezeichnen. Der Dienst ließ sich verschieben, während seine äußere Adresse gleich blieb. Unterschiedliche Adressen auf demselben Host konnten unterschiedliche Zugriffsregeln sichtbar machen, ohne den Nutzern ein neues Protokoll oder einen Sonderport aufzubürden. Eine Firewall konnte nur die Dienstadresse freigeben, sofern die Serverprozesse korrekt gebunden waren. Die bekannten Risiken adressbasierter Authentisierung blieben bestehen.

Das Papier erwog, DNS um Portangaben zu erweitern. Dagegen stand die Umstellung aller betroffenen Clients. Mehr Semantik in der Adresse nutzte dagegen den bereits vorhandenen Verbindungspfad der Anwendungen.

Die gesparte Clientänderung belastete nun ein einziges Feld mit Rollen unterschiedlicher Dauer: Hostort, Dienstidentität, Zugriffsklasse, Nutzersitzung, Mobilitätsanker und Abrechnungskategorie. Eine Dienstadresse konnte einen Serverwechsel überdauern. Eine Nutzeradresse endete mit der Sitzung. Eine Preistabelle konnte wechseln, obwohl die Zielbits gleich blieben. Die Adresse bewahrte diese Zeitbezüge nicht von selbst.

Wer zahlt, war nur eines von mehreren Abrechnungsfeldern

RFC 1681 nannte vier mögliche Modelle nutzungsabhängiger Gebühren. Beim herkömmlichen „pay as you go“ zahlte jeder Host für seine eigenen Pakete, womit beide Kommunikationsseiten Kosten tragen konnten. Im Modell „caller pays“ zahlte der Initiator. Ein R-Gespräch belastete den Empfänger. Ein Premiumdienst nach Art einer amerikanischen „900“-Nummer ließ den Aufrufer einen Aufpreis an den Server zahlen.

Deshalb mussten Anrufer und Empfänger vorab wissen, wer belastet würde. Erst im Nachhinein von entstandenen Kosten zu erfahren, war nicht hinnehmbar.

Die Zahlerrolle definierte aber noch keinen Preis. RFC 1125 hatte Abrechnungseinheit, Berechnungsgrundlage, tatsächlichen Betrag, Zahler oder Empfänger, maßgeblichen Paketzähler und Obergrenzen getrennt. Ein korrekt erkanntes „caller pays“-Bit sagte weder, ob Byte, Paket oder Sitzung berechnet wurden, noch welche Tarifversion galt, welcher Zähler maßgeblich war oder welcher Höchstbetrag genehmigt wurde.

Der Tabellenindex aus RFC 1681 machte die Abhängigkeit sogar sichtbar. Zeigte eine Adresse auf eine Zeile, lag die Regel in dieser Zeile, unter der Verantwortung eines Betreibers und während eines bestimmten Gültigkeitszeitraums. Wer nur die Adresse archivierte, konnte den Schlüssel behalten und die damalige Bedeutung verlieren.

Der Grenzrouter durfte ablehnen, nicht für den Nutzer einwilligen

Der organisatorische Grenzrouter war eine begrenzte, überprüfbare Kontrollstelle. RFC 1681 stellte sich vor, dass anonyme Arbeitsplätze in einem Studentenwohnheim keine R-Gespräche annehmen dürften. Die Organisation konnte kostenpflichtige Zielklassen unterbinden, ohne auf neue Bedienoberflächen in jedem Programm zu warten.

Eine Freigabe war dennoch keine menschliche Zustimmung. Der Rechner konnte gemeinsam genutzt, die Anfrage automatisiert und der Kontoinhaber vom aktuellen Sitzungsnutzer verschieden sein. Eine Vollmacht konnte nur bis zu einem Betrag reichen. Der entfernte Anbieter konnte eine andere Tabellenversion verwenden. Der Router konnte seine eigene Regel korrekt vollziehen, während die spätere Forderung strittig blieb.

RFC 1681 schlug zusätzlich eine eigene IP-Adresse für jeden angemeldeten Nutzer vor. Router sammelten Nutzung weiterhin nach Adresse; der Host protokollierte die Zuordnung zur Sitzung; die Abrechnung erfolgte offline. Unterschiedliche Nutzerklassen könnten Adressformen erhalten, die teure Dienste erlaubten oder sperrten.

Das verbesserte die Verknüpfbarkeit von Aufzeichnungen, nicht den Identitätsbeweis. Nötig wären Routerzählung, zeitgebundenes Zuordnungsprotokoll des Hosts, Authentisierung, Ausgabenbefugnis, gültige Tariftabelle und Dienstnachweis. Selbst eine nutzerspezifische Adresse bewies nicht, wer die Sitzung im entscheidenden Moment bediente oder genau diese Ausgabe billigte.

Die Veröffentlichung blieb Teil der IPng-Akte

Der RFC-Editor-Eintrag führt RFC 1681 als Informational. Das Papier antwortete auf die IPng-Ausschreibung in RFC 1550 und erklärte ausdrücklich, dass seine Veröffentlichung keine Annahme der Ideen durch den IPng-Bereich bedeute. RFC 1550 ordnete solche Beiträge als Arbeitsmaterial und Teil der historischen Überlieferung des Auswahlprozesses ein.

Spätere Standards liefern Vergleiche, aber keine nachträgliche Abnahme. RFC 4291 weist IPv6-Adressen Schnittstellen zu und erlaubt mehrere Adressen verschiedener Typen und Reichweiten an einer Schnittstelle. Daraus folgt weder die Übernahme von Abrechnungsbits noch eine kausale Linie von RFC 1681 zur IPv6-Architektur.

RFC 2782 schuf für die Dienstsuche einen DNS-SRV-Eintrag mit Dienst, Protokoll, Priorität, Gewicht, Port und Ziel sowie anwendungsbezogenen Nutzungsregeln. SRV findet einen Dienst. Es standardisiert keinen Preis, Zahler, Zustimmungsbeleg, Zähler oder Rechnungsanspruch.

Auch die Empfehlung, pro Host Raum für 2^6 und vielleicht 2^8 zusätzliche Adressen vorzusehen, war eine Planungsreserve für mögliche Verwendungen, besonders für das aufwendige Modell einer Adresse je Nutzer. Sie war weder ein gemessener Durchschnitt noch ein Zuteilungsrecht.

Von der Adresse bis zur Zahlung führt keine Abkürzung

Eine nachvollziehbare Kette müsste getrennt erhalten: gewählte Zieladresse; Klasse oder Tabellenindex; damals gültige Tabelle und Verantwortlicher; Grenzentscheidung; authentisiertes Konto und handelnder Principal; vor Bindung gezeigte Bedingungen und Antwort; Annahme und nutzbare Erbringung des Dienstes; Maßeinheit, Zähler und Zeitraum; Rechnungsberechnung, Zahler und Grenzen; schließlich Zahlung, Storno oder Streitstand.

Kein Beleg ersetzt den nächsten. Eine erkannte Klasse beweist keine aktuelle Tabelle. Routerzulassung beweist keine Zustimmung. Eine Verbindung beweist keine Leistung. Ein Paketzähler beweist keinen Tarif. Eine Rechnung beweist keine Begleichung.

Heng Lus Running-Code Primacy verlangt, Vorschlag, Veröffentlichung, Annahme und beobachteten Betrieb auseinanderzuhalten. Minimum Initial Specification trennt gemeinsame Interoperabilitätsregeln von Geschäftsvereinbarungen, die lokal bleiben können. Reality, Not Advocacy setzt die redaktionelle Grenze: Die Idee wird weder wiederbelebt noch verspottet, sondern in ihrem belegbaren Umfang beschrieben.

RFC 1681 wollte dem Netz eine Regel zeigen, bevor es das Geld eines Beteiligten verbrauchte. Dauerhaft ist nicht der unbelegte Adresscode, sondern die Reihenfolge: Ein früher Hinweis schützt nur dann, wenn Identität, Befugnis, Leistung, Messung und Abrechnung weiterhin je einen eigenen Nachweis besitzen.

Quellen