Zusammenfassung

  • Der Verkauf einer dedizierten Verbindung belegt eine Konnektivitätsleistung, nicht automatisch die Weitergabe eines IPv4-Blocks an den Kunden.
  • In der öffentlichen Diskussion vom September stehen eine Portalbeobachtung und ein Beispiel eines brasilianischen Anbieters. Ob Adressen überlassen wurden und wie der Fall einzuordnen wäre, bleibt offen.

Am 14. September fragte ein Teilnehmer auf der LACNIC-Politikliste, warum eine Option zur Weitergabe in MiLACNIC, nicht aber in Registro.br zu sehen sei und ob eine Frist gelte. Am folgenden Tag schilderte ein Teilnehmer von Registro.br die Zusammenarbeit zwischen LACNIC und den nationalen Internetregistern (NIRs) bei der Umsetzung. Zugleich habe jedes System eigene Probleme. Eine weitere Antwort lautete, die Option sei in MiLACNIC für eine dem Verfasser bekannte ASN sichtbar gewesen; gebraucht habe er sie noch nicht. Anlass für die Frage sei ein konkreter Fall: Ein brasilianischer Internetanbieter verkaufe einer nicht-brasilianischen Firma eine dedizierte Leitung. (Frage vom 14. September; Antwort zur Umsetzung; Einordnung des Beispiels)

Das Beispiel ist greifbar. Für eine Schlussfolgerung zur Policy fehlen jedoch gerade die entscheidenden Angaben. Die Nachricht sagt nicht, dass der Anbieter dem Kunden ein Präfix überlassen, der Kunde Routen angekündigt oder eine autonome Systemnummer gehabt hätte. Auch ein Wechsel der Adressinhaberschaft wird nicht erwähnt. Der Standort des Kundennetzes bleibt offen. Eine dedizierte Leitung belegt eine Dienstleistungsbeziehung für Konnektivität. Ohne weitere Nachweise belegt sie nicht, dass der Kunde eine Nummernressource erhalten hat.

Genau um diese Unterscheidung geht es in LAC-2025-5, der LACNIC-Policy „Weitergabe von IPv4-Ressourcen an Dritte“. Die offizielle Seite führt die Ratifikation vom 24. März 2026 auf. Der geltende Text bezieht sich ausschließlich auf IPv4 und legt Voraussetzungen für eine zulässige Weitergabe fest: Anforderungen an den Empfänger, Größenbegrenzungen für den Block, Schwellenwerte für aktuelle Nutzung oder unmittelbaren Bedarf, eine WHOIS-Verknüpfung des Blocks mit der ASN des Empfängers und ein Ereigniseintrag im öffentlichen Bewegungsprotokoll. Die letztendliche Verantwortung verbleibt beim LACNIC-Mitglied, das die Ressource weitergibt. Nach einer Übertragung oder Rückgewinnung gilt zudem eine Wartezeit. (geltender ratifizierter Text)

Diese Sicherungen machen nicht aus jedem Kundenanschluss eine Ressourcenübertragung. Sie erhöhen vielmehr die Bedeutung der richtigen Ausgangsklassifizierung. Verkauft ein Anbieter Transport und nutzt weiterhin seinen eigenen Adressraum, beweist der Kauf einer dedizierten Leitung keine Weitergabe. Stellt der Anbieter dem Kunden zusätzlich einen Block zur operativen Nutzung bereit, lässt sich diese Ressourcenbeziehung nicht durch das Etikett „Leitung“ beseitigen. Die öffentlichen Nachrichten enthalten nicht genug Einzelheiten, um zwischen diesen Möglichkeiten zu wählen.

Entscheidend ist der Ressourcenzugriff, nicht der Produktname

Der Leitfaden von LACNIC für Ressourcenanträge hilft, beide Ebenen auseinanderzuhalten. Anbieter von Webhosting, Colocation, virtuellen privaten Servern oder dedizierten Leitungen werden im Kontext eines Internetdienstanbieters betrachtet. Davon unterscheidet der Leitfaden Organisationen, die ihre eigene Infrastruktur betreiben, ohne Adressblöcke an Dritte weiterzuweisen. Anträge aus Brasilien und Mexiko laufen über die jeweils zuständigen NIRs. (LACNIC-Leitfaden)

Der Leitfaden ordnet den Fall aus der Mailingliste nicht ein. Er zeigt aber, warum „Leitung“ kein verlässlicher Ersatz für die Policy-Frage ist. Eine Leitung beschreibt, was der Kunde kauft: Konnektivität zwischen Netzpunkten. Ein Ressourceneintrag beschreibt etwas anderes: welche Organisation einen IPv4-Block erhält und welche Nachweise diese Organisation mit der Ressource verbinden. Ein Vertrag oder eine Rechnung kann beides bündeln; das eine kann auch ohne das andere vorkommen.

Diese Grenze ist in der Infrastrukturökonomie vertraut. Unternehmen bündeln Kapazität, Geräte, Betrieb und Adressierung, weil Kunden meist ein nutzbares Ergebnis wollen und nicht eine Liste von Vorleistungen, die sie einzeln koordinieren müssen. Das senkt Abstimmungskosten. Zugleich kann es verschleiern, wer eine knappe Ressource kontrolliert und die damit verbundenen Registerpflichten trägt. Die richtige Reaktion ist nicht, jedes Bündelangebot als Weitergabe einzustufen. Zuerst müssen Ressource und Empfänger festgestellt werden, erst dann lässt sich die dafür geschaffene Regel anwenden.

LAC-2025-5 macht diese Prüfung konkret. Der Block muss innerhalb des geltenden Größenrahmens liegen. Der Empfänger muss die Anforderungen an ASN und IPv6 erfüllen. Beim Nutzungsmaßstab zählen entweder bestehende Nutzung oder unmittelbarer Bedarf; davon zu unterscheiden ist ein Plan, binnen eines Jahres den höheren Schwellenwert zu erreichen. WHOIS muss den Block mit der Empfänger-ASN verbinden, das öffentliche Bewegungsprotokoll Block, ASN, Datum sowie Beginn oder Ende des Ereignisses ausweisen. Die Verantwortung bleibt beim weitergebenden Mitglied.

Das sind keine allgemeinen Signale einer Kundenbeziehung, sondern Felder einer bestimmten Form der Ressourcenverwaltung.

Auch die Staatsangehörigkeit des Kunden sagt nichts über den Standort seines Netzes aus. „Nicht-brasilianische Firma“ beschreibt das Unternehmen so, wie es der Teilnehmer benannt hat. Daraus folgt weder, wo Router und Nutzer stehen, noch welcher Adressraum eingesetzt wird. Es sagt auch nicht, ob der Kunde eine ASN besitzt oder die Adressen des Anbieters nutzt. Geografie kann beeinflussen, welches NIR beteiligt ist; sie ersetzt nicht die Angaben zu Empfänger und Ressource, die die Policy verlangt.

Eine Portalabweichung ist eine offene Frage, kein Fehlernachweis

Der Austausch vom September sollte als begrenzter Hinweis zum Umsetzungsstand gelesen werden. Am 1. September hatte der LACNIC-Policy-Assistent erklärt, die Umsetzung solle vor Jahresende beginnen, zunächst mit grundlegenden Aspekten; technische Herausforderungen seien noch zu bearbeiten. Danach berichtete ein Teilnehmer, die Option in einem System zu sehen, im anderen aber nicht. Eine Antwort verwies auf gemeinsame Umsetzungsarbeiten und systemspezifische Probleme. Ein weiterer Teilnehmer sagte, die Option für eine bekannte ASN in MiLACNIC gesehen, aber noch nicht verwendet zu haben. (Umsetzungsmitteilung vom 1. September)

Die Nachrichten zeigen, dass Nutzer während der laufenden Umsetzung wissen wollten, wie eine neue Regel in verschiedenen Oberflächen abgebildet wird. Sie belegen weder einen Defekt eines Portals noch die Verfügbarkeit der Option für alle MiLACNIC-Konten. Sie zeigen auch nicht, dass Registro.br sie zu diesem Zeitpunkt bereits anbieten musste oder dass eine Frist versäumt wurde. Es handelt sich um datierte Beobachtungen und Erklärungen, nicht um einen kontrollierten Systemvergleich.

Das praktische Problem bleibt dennoch bestehen: Eine Policy, die Empfänger, Block, ASN und ein datiertes Ereignis voraussetzt, muss für Mitglieder und gegebenenfalls NIRs nutzbar sein. Findet ein Konto die Option nicht, kann eine Meldung verzögert oder unsicher werden. Die Kosten sollte man jedoch anhand bestätigter Fälle messen, nicht aus einem Austausch ableiten. Kontoberechtigung, Ressourcenbeziehung, Rollout-Phase und Vertrautheit mit der Oberfläche sind mögliche Erklärungen, bis der Betreiber eine davon bestätigt.

Die sachgerechte Reihenfolge beginnt mit dem Adressblock. Danach ist festzustellen, wer ihn erhält oder kontrolliert, welche ASN der Empfänger hat und welcher Registereintrag relevant ist. Anschließend lässt sich prüfen, ob die Voraussetzungen der Policy gelten und ob ein öffentliches Ereignis erforderlich ist. Erst dann folgt die Frage, ob das Portal den Eintrag ermöglicht. Aus einem fehlenden Menü auf eine Weitergabe zu schließen, macht aus einer Unsicherheit der Benutzeroberfläche eine rechtliche oder technische Feststellung.

Diese Reihenfolge schützt beide Seiten. Ein Anbieter sollte nicht allein deshalb ein Ressourcenereignis melden müssen, weil ein Kunde eine dedizierte Leitung kauft, wenn keine zulässige Weitergabe vorliegt. Umgekehrt sollten Kunde und Register nicht ohne Ressourcennachweis bleiben, wenn ein Block tatsächlich zur Nutzung durch den Kunden bereitgestellt wird, nur weil der Vertrag von einer Leitung oder einem Managed Service spricht. Maßgeblich ist die tatsächliche Zuweisung und Kontrolle des Blocks, dokumentiert mit den in der Policy genannten Nachweisen.

Was ein brauchbarer Umsetzungsbeleg zeigen müsste

Ein verlässlicher Ablauf sollte dem Mitglied vor dem Absenden die Ressourcenbeziehung sichtbar machen: den Block, den vorgesehenen Empfänger, dessen ASN, die Grundlage aus Nutzung oder unmittelbarem Bedarf sowie Beginn oder Ende der Vereinbarung. Wenn die Policy greift, sollten Ressourceneintrag und öffentliches Ereignisprotokoll bei diesen Angaben übereinstimmen. Greift sie nicht, weil der Anbieter die Adressen behält und keinen Block an Dritte weitergegeben hat, sollte die Begründung für Kunde und Sachbearbeitung ebenso klar sein.

Für LACNIC und die NIRs ist die Umsetzung mehr als eine Schaltfläche. Mitglieder müssen wissen, welches System für ihr Konto zuständig ist, ob der passende Ablauf alle erforderlichen Angaben aufnehmen kann und ob sich ein übermitteltes Ereignis mit dem Ressourceneintrag abgleichen lässt. Der September-Austausch beantwortet das nicht. Ein späteres Update könnte Rollout-Stufen, Portalzuständigkeiten und den Weg für Konten oder Ressourcen unter NIR-Verwaltung erklären.

Das verlangt nicht, Kundenverträge oder vertrauliche Geschäftsdaten zu veröffentlichen. Die Policy sieht selbst ein öffentliches Ereignis mit festgelegten Feldern vor. Eine brauchbare Prozessbestätigung kann diese Felder und den Systemstatus zeigen, ohne kommerzielle Vertragsbedingungen offenzulegen. Gibt es keine zulässige Weitergabe, kann eine private Support-Antwort genügen; das öffentliche Protokoll darf kein nicht stattgefundenes Ereignis nahelegen.

Die Schlussfolgerung ist begrenzt, aber wichtig. Eine dedizierte Leitung kann Adressen transportieren, und ein kommerzielles Angebot kann mehrere Netzkomponenten bündeln. Die Antwort steht jedoch weder im Marketingnamen der Leistung noch in der Nationalität des Kunden oder darin, ob eine Portaloption erscheint. Entscheidend ist, wer die IPv4-Ressource erhält, wie diese Beziehung dokumentiert wird und ob die geltenden Voraussetzungen erfüllt sind. Die öffentliche Evidenz wirft die Frage auf, beantwortet sie aber nicht.

Weitere offizielle Sprachfassungen von LAC-2025-5