IPv8: Ich mache mir das Internet, wie es mir gefällt

Wenn IPv4 als Initialzündung des modernen Internets gelten kann, dann ist IPv6 die seit Jahrzehnten geplante und inzwischen vielerorts gelebte Zukunft des Netzes.

Ein IETF-Entwurf (Draft) von Jamie Thain aus Bermuda will IPv6 überflüssig machen, das Internet neu erfinden und zu einhundert Prozent rückwärtskompatibel sein. Der Entwurf mit dem provokanten Namen Internet Protocol Version 8 wurde im April 2026 eingereicht und erhitzt seitdem die Gemüter.

Nicht, weil er als realistischer Nachfolger für IPv6 gilt, sondern weil viele Netzwerkexperten ihn als technisch fragwürdigen Alleingang mit Hang zum Größenwahn betrachten.

Er demonstriert, wie sehr der offene Einreichungsprozess der IETF zugleich Stärke und Schwäche ist. Jeder darf mitreden, doch am Ende trennt sich die Spreu vom Weizen. Der Vorfall trifft einen wunden Punkt. Nach 25 Jahren schleppender IPv6-Migration, steigendem geopolitischem Druck rund um Huaweis New IP und einer Community, die bei jeder neuen Versionsnummer reflexartig zuckt, entfaltet selbst ein aussichtsloser Einzelvorschlag erstaunliche Wirkung.

Das neue Internet

Im Entwurf sollen drei grundlegende Probleme des heutigen Internets gleichzeitig gelöst werden.

Das erste Problem ist der Mangel an IPv4-Adressen, den der Entwurf beheben möchte. Die vierte Version des Internet Protocols verwendet 32-Bit-Adressen und kann dadurch rund 4,3 Milliarden eindeutige Adressen bereitstellen. Diese Anzahl ist angesichts von Milliarden Smartphones, Servern, IoT-Geräten und Heimroutern nicht mehr ausreichend. Deshalb werden seit Jahren Techniken wie Network Address Translation (NAT) eingesetzt, bei denen sich viele Geräte eine einzige öffentliche IP-Adresse teilen.

Zweitens will der Entwurf die verteilte und uneinheitliche Netzwerkverwaltung beseitigen. Gemeint ist damit, dass Netzwerke heute über viele unterschiedliche Protokolle, Werkzeuge und Verwaltungsoberflächen konfiguriert und überwacht werden. Für Administratoren bedeutet das einen hohen Aufwand, da es keinen einheitlichen Mechanismus gibt, um alle Komponenten zentral zu steuern.

Drittens soll das unbegrenzte Wachstum der globalen BGP-Tabelle gestoppt werden. Das Border Gateway Protocol (BGP), ist das Routing-Protokoll, das festlegt, über welche Wege Datenpakete durch das Internet transportiert werden. Jeder Internetanbieter kündigt dabei an, für welche IP-Adressbereiche er erreichbar ist. Diese Informationen werden weltweit gesammelt. Die daraus entstehende Routing-Tabelle umfasst inzwischen weit über eine Million Einträge und wächst kontinuierlich weiter. Das stellt hohe Anforderungen an Speicher und Rechenleistung der Router im Internet-Backbone.

Der Entwurf behauptet, dass IPv6 auch nach 25 Jahren nur einen Minderheitsanteil des weltweiten Internetverkehrs erreiche und der parallele Betrieb von IPv4 und IPv6 wirtschaftlich nicht tragbar sei.

Aus dieser Analyse zieht der Autor den Schluss, dass nicht eine Vereinfachung, sondern ein noch umfassenderer Neuansatz erforderlich sei; gebündelt unter der bewusst provokanten Bezeichnung IPv8, einer Versionsnummer, die bereits in den 1990er Jahren mit dem PIP-Vorschlag verbunden war.

Der Entwurf im IETF-Datatracker

Begleitet wird der Kern-Entwurf zumindest dem Anspruch nach von einem ganzen Paralleluniversum aus BGP8, OSPF8, IS-IS8, WHOIS8, NetLog8, WiFi8 und SNMPv8. Im Hauptdokument werden diese Begleit-Spezifikationen zwar aufgelistet, die angegebenen Drafts sind jedoch nicht bei der IETF hinterlegt. Was wie ein kompletter Protokoll-Stack wirkt, ist offenbar vorwiegend eine Verweiskulisse.

Wer ist Jamie Thain?

Öffentlich taucht Thain bereits 2004 auf, damals als CTO des bermudianischen Internetproviders Transact im Kontext des Sasser-Wurms. In den folgenden Jahren arbeitete er laut Unternehmensprofilen als Technologiearchitekt im Telekommunikationsumfeld und war unter anderem an der Planung von 4G-LTE-Netzen, FTTH-Infrastrukturen und Unterseekabelsystemen beteiligt.

Später war Thain CTO bei Bluewave Bermuda, einem lokalen WISP- und ISP-Betreiber. Gemeinsam mit Jack Benaim gründete er anschließend den Bermuda-Inkubator InnoFund. InnoFund betrieb zusammen mit dem Inkubator DMZ den Startup-Accelerator i3 powered by DMZ. Daneben existiert auch BPMS Ltd, eine weitere von Thain mitbegründete Firma. Als aktuelle Zugehörigkeit führt der IPv8-Draft One Limited auf.

Doch welche Motivation steckte hinter dem Draft? Thain wollte ursprünglich keine neue Version des Internet-Protokolls entwickeln, sondern eine schlüsselfertige Komplettlösung für den Betrieb eines Netzwerks erstellen. Weil ihm IPv6 für dieses Vorhaben zu komplex erschien, entwickelte er während eines krankheitsbedingten Ausfalls mithilfe von KI innerhalb von fünf Tagen einen Vorschlag für einen neuen Protokoll-Stack.

IPv4 mit Vorwahl

Thains Kernidee ist überraschend konservativ. Statt IPv6 mit seinen 128-Bit-Adressen und neuem Header abzulösen, erweitert IPv8 den klassischen IPv4-Header um acht zusätzliche Oktette.

Architektonisch sieht der Entwurf einen 64-Bit-Adressraum vor, der wie folgt aufgebaut ist:

r.r.r.r.n.n.n.n

Die ersten 32 Bit codieren hierbei laut Spezifikation direkt eine 32-Bit-ASN. Eine Autonomous System-Nummer (ASN) ist die eindeutige Kennung eines Netzbetreibers oder einer Organisation im globalen Routing.

Große Provider wie die Deutsche Telekom, Cloudflare oder Google besitzen jeweils eine oder mehrere ASNs. Jede Organisation mit einer ASN erhält damit jeweils einen eigenen IPv4-Adressraum mit knapp 4,3 Milliarden Hostadressen. Im Entwurf stellt sich dies beispielhaft wie folgt dar:

64496.192.0.2.1  = 0.0.251.240.192.0.2.1
64497.192.0.2.1  = 0.0.251.241.192.0.2.1

Im Kern handelt es sich damit um eine Rückkehr zu einer frühen 64-Bit-Adressidee, die Steve Deering in der Vorgeschichte von IPv6 verfolgte, mit dem Unterschied, dass Thain die obere Hälfte des Adressraums fest an ASNs bindet.

Die zentrale Verkaufsbotschaft des Entwurfs lautet, dass IPv4 eine Teilmenge von IPv8 sei. Gemeint ist damit, wenn die ersten vier Oktette einer IPv8-Adresse auf 0.0.0.0 gesetzt werden, soll die Adresse wie eine ganz normale IPv4-Adresse behandelt werden.

Aus dieser Konstruktion leitet der Autor die weitreichende Behauptung ab, dass bestehende Geräte, Anwendungen und Netzwerke nicht verändert werden müssen, um an einem IPv8-Netz teilzunehmen. Der Übergang könne schrittweise erfolgen, ohne Stichtag und ohne erzwungene Migration. Der Entwurf fasst das selbstbewusst zusammen:

No existing device, application, or network requires modification. The suite is 100% backward compatible. There is no flag day and no forced migration at any layer.

Diese Behauptung kollabiert spätestens im Abschnitt über das Header-Format:

IPv8 uses IP version number 8 in the Version field. The header extends IPv4 by replacing the 32-bit src/dst address fields with 64-bit equivalents.

Bestehende IPv4-Stacks und Router würden Pakete mit der Versionsnummer 8 aber in aller Regel verwerfen.

Zone Server

Das eigentliche Kern des Entwurfs verbirgt sich nicht in der Adressmathematik, sondern im Abschnitt mit dem Namen IPv8 Management Philosophy.

Zentrales Element der Architektur ist der sogenannte Zone Server. Dabei handelt es sich um ein redundant ausgelegtes Serverpaar, bei dem beide Systeme gleichzeitig aktiv sind und gemeinsam eine Vielzahl bislang getrennter Dienste in einer einzigen Infrastruktur bündeln.

Im IPv8-Entwurf übernehmen diese Zone Server gemeinsam DHCP, DNS, Authentifizierung, Logging und Routenvalidierung. Fällt einer aus, bleibt der andere ohne Umschaltung weiter in Betrieb. Der Entwurf verlangt genau zwei sogenannte Zone Server pro Subnetz.

Dabei sollen die ebenfalls neuen Protokolle wie DHCP8, DNS8, NTP8, NetLog8, OAuth8, WHOIS8, ACL8 und XLATE8 auf diesen Systemen laufen. Jeder Endpunkt erhält bereits mit einer einzigen DHCP8-Discover-Antwort sämtliche Informationen über die verfügbaren Dienste.

Vorgeschrieben sind zwei Zone Server pro Subnetz, die auf den Adressen .254 und .253 betrieben werden. Hosts mit geraden Adressen verwenden standardmäßig den einen Server, Hosts mit ungeraden Adressen den anderen.

Komplexität gewünscht

Zusätzlich setzt der Entwurf voraus, dass in jedem Netzwerk ein zentraler Switch als sogenannter PVRST-Root fungiert. Per-VLAN Rapid Spanning Tree (PVRST) ist eine von Cisco Systems entwickelte proprietäre Variante des Spanning-Tree-Protokolls, die Schleifen in Ethernet-Netzen verhindert.

In größeren Ethernet-Netzen existieren oft mehrere redundante Verbindungen zwischen Switches. Ohne Schutzmechanismen könnten dadurch Schleifen entstehen, bei denen Datenpakete endlos im Kreis laufen. Spanning Tree-Protokolle verhindern das, indem sie einen Root-Switch auswählen und anschließend überflüssige Verbindungen deaktivieren.

Bemerkenswert ist, dass der Entwurf eine herstellerspezifische Technologie zur festen Voraussetzung eines globalen Internetprotokolls macht. Ein offener Internetstandard sollte sich nicht auf proprietäre Mechanismen eines einzelnen Herstellers stützen.

Auch das Routing wird vollständig neu organisiert. Vorgesehen sind eBGP8, IBGP8 und OSPF8; IS-IS8 bleibt als unterstützte Option erhalten, während die Protokolle RIP und EIGRP ausdrücklich als veraltet gelten. Über die Grenzen von autonomen Systemen hinweg sollen nur Präfixe bis maximal /16 propagiert werden. Jede Route muss vor ihrer Installation über die neue WHOIS8-Infrastruktur validiert werden, die der Entwurf als globale kritische Infrastruktur versteht. Die weltweite Routingtabelle soll dadurch strukturell auf die Anzahl der autonomen Systeme begrenzt werden.

Zur Pfadbewertung führt der Entwurf den sogenannten Cost Factor ein, einen 32-Bit-Wert, der Round-Trip-Time, Paketverlust, Congestion-Window, Sitzungsstabilität, Linkkapazität, wirtschaftliche Vorgaben und geografischer Entfernung kombiniert. So versucht der Entwurf, technische Messwerte, physikalische Grenzen und sogar wirtschaftliche Interessen in einer einzigen Zahl zu vereinen. Diese Vermischung sehr unterschiedlicher Einflussfaktoren wird von vielen Fachleuten als übermäßig komplex und praktisch kaum umsetzbar angesehen.

Im Bereich Sicherheit verfolgt der Entwurf einen sehr weitreichenden Ansatz. Jede verwaltbare Komponente, vom Endgerät über den Switch bis zum Router, muss sich mithilfe von OAuth2 und JSON Web Tokens eindeutig authentifizieren. Bevor ein Gerät am Netzwerk teilnehmen darf, muss es also nachweisen, dass es dazu berechtigt ist.

Auch ausgehende Verbindungen werden streng kontrolliert. Bevor ein Paket das Netzwerk verlassen darf, muss zunächst ein DNS8-Lookup erfolgreich sein. Erst dann wird ein entsprechender XLATE8-Eintrag angelegt, der die Verbindung überhaupt ermöglicht. Zusätzlich wird überprüft, ob das Zielnetz in der WHOIS8-Infrastruktur als gültig registriert ist. Schlagen diese Prüfungen fehl, wird die Verbindung blockiert.

Die Netzwerkkarten selbst sollen nicht überschreibbare Hardware-Limits durchsetzen, die nur durch explizite Anweisung des Zone Servers angehoben werden können. Konkret sind das maximal zehn Broadcasts pro Sekunde, zehn unauthentifizierte Pakete pro Sekunde und einhundert authentifizierte Pakete pro Sekunde.

Schließlich verlangt der Entwurf eine ganze Reihe offizieller Zuweisungen durch die Internet Assigned Numbers Authority. Die IANA verwaltet weltweit zentrale Nummern- und Adressbereiche des Internets, darunter IP-Versionen, DNS-Recordtypen und spezielle Netzwerkbereiche.

Der Entwurf beantragt zunächst, die Versionsnummer 8 für ein neues Internetprotokoll zu reservieren, obwohl diese Bezeichnung historisch bereits mit PIP verbunden war. Ferner sollen mehrere bekannte IPv4-Adressbereiche für neue Zwecke fest zugewiesen werden: 127.0.0.0/8 als interner Bereich für Zone Server, 100.0.0.0/8 für RINE-Peering und 222.0.0.0/8 für interne Verbindungen.

Zusätzlich fordert der Entwurf einen neuen DNS-Recordtyp mit dem Namen A8, spezielle Reservierungen für ASNs sowie einen eigenen Multicast-Adressbereich. Damit IPv8 funktionieren könnte, müssten zahlreiche zentrale Ressourcen des Internets offiziell neu vergeben und dauerhaft reserviert werden.

Angriff auf das Schichtenmodell

Was der Entwurf als elegante Vereinheitlichung präsentiert, verletzt ein grundlegendes Prinzip des Internets: die Trennung der Protokollschichten. IP arbeitet auf einer sehr niedrigen Ebene und hat im Wesentlichen nur die Aufgabe, Pakete von A nach B zu transportieren.

OAuth2 und JSON Web Tokens gehören dagegen in eine deutlich höhere Schicht, in der sich Anwendungen um Benutzeranmeldung und Zugriffsrechte kümmern. Der IPv8-Entwurf vermischt beide Ebenen und verlangt damit von einfachen Netzwerkgeräten Aufgaben, für die sie weder konzipiert noch ausgelegt sind.

Was IPv8 ignoriert

Bemerkenswert ist nicht nur, was der IPv8-Entwurf vorschlägt, sondern auch, was er komplett ausblendet. Zahlreiche Technologien, die genau die von ihm beschriebenen Probleme bereits heute adressieren, werden mit keinem Wort erwähnt. Dazu gehören moderne Routing-Erweiterungen für IPv6, etablierte Verfahren zur Absicherung von BGP-Routen sowie bewährte Übergangstechniken, mit denen IPv4 und IPv6 seit Jahren parallel betrieben werden.

So ignoriert der Entwurf beispielsweise RPKI und ROA, obwohl diese Mechanismen bereits heute die Herkunft von Routen kryptografisch absichern. Stattdessen entwirft er mit WHOIS8 eine vollkommen neue globale Validierungsinfrastruktur.

Gleiches gilt für NAT64, 464XLAT und andere Techniken, die in Mobilfunknetzen weltweit produktiv eingesetzt werden, um IPv6-only-Infrastrukturen mit IPv4-Diensten zu verbinden.

Selbst grundlegende Bestandteile moderner IPv6-Netze wie SLAAC, Router Advertisements und DHCPv6 werden übergangen und durch neue Eigenentwicklungen wie DHCP8 ersetzt.

Für die Authentifizierung an Switch-Ports schlägt der Entwurf OAuth2 vor, ohne das etablierte Verfahren 802.1X mit EAP-TLS auch nur zu erwähnen. Insgesamt entsteht der Eindruck, dass der Entwurf viele Probleme neu erfindet, ohne bestehende Lösungen oder die Erfahrungen der letzten zwei Jahrzehnte zu berücksichtigen.

Reaktionen

Besonders häufig wird kritisiert, dass der Entwurf bestehende und bereits standardisierte Lösungen ignoriert, gleichzeitig aber eine Vielzahl neuer Protokolle, Dienste und zentraler Kontrollinstanzen einführt.

Viele Kritiker sehen in dem Entwurf daneben ein von Grund auf kontrollorientiertes Protokoll, das sich besonders gut für zentrale Überwachung und Regulierung eignet. Wer den Zone Server, die WHOIS8-Registry oder die zentrale Authentifizierungsinfrastruktur betreibt, erhält letztlich die Kontrolle über das gesamte Netzwerk.

Die versprochene vollständige Rückwärtskompatibilität gilt vielen als nicht glaubwürdig, weil das Paketformat, die Routing-Protokolle und zahlreiche Infrastrukturkomponenten grundlegend verändert werden. Auch die enge Verzahnung von IP mit OAuth2, zentralen Authentifizierungsdiensten und globalen Validierungsinstanzen wird als deutlicher Bruch mit den dezentralen Grundprinzipien des Internets gesehen.

Mehrere Analysen heben hervor, dass der Entwurf reale Probleme wie IPv6-Migrationskosten, BGP-Wachstum und operative Komplexität durchaus korrekt benennt. Die vorgeschlagene Lösung wird jedoch als unverhältnismäßig und praktisch kaum umsetzbar bewertet. Insbesondere die starke Zentralisierung, die Abhängigkeit von neuen kritischen Infrastrukturen und die Vermischung unterschiedlichster Technologien stoßen auf breite Skepsis.

Bemerkenswert ist auch, was ausbleibt. Auf den etablierten Fachforen und Mailinglisten der Internet-Community blieb der Entwurf weitgehend ohne ernsthafte Unterstützung. Prominente Stimmen aus der Routing- und IETF-Welt äußerten sich entweder gar nicht oder nur am Rande. Dieses Schweigen ist in einem Umfeld, in dem tragfähige Ideen normalerweise schnell fachliche Diskussionen auslösen, selbst eine deutliche Form der Einordnung.

Eine kurze Phantomologie

Wer IPv8 sagt, betritt einen Friedhof. Die niedrigen Versionsnummern des Internet Protocols sind seit Jahrzehnten vergeben, verworfen oder Teil der Netzfolklore geworden.

Die Versionen 0 bis 3 stammen aus der Frühzeit des Internets. Sie tauchten in den experimentellen Vorläufern von TCP/IP in den späten 1970er Jahren auf, erreichten aber nie einen produktiven Einsatz. Mit IPv4, spezifiziert in RFC 791 aus dem Jahr 1981, entstand schließlich das Protokoll, das bis heute das Fundament des Internets bildet.

Die Version 5 wurde für ST und ST-II verwendet, ein Streaming-Protokoll mit Reservierungsmechanismen für Echtzeitdaten. IPv6 ging aus Steve Deerings SIPP-Entwurf hervor und wurde Mitte der 1990er Jahre als offizieller Nachfolger von IPv4 standardisiert. IPv7 stand für TP/IX und später CATNIP, zwei alternative Vorschläge, die sich nie durchsetzen konnten.

Besonders relevant für den aktuellen Fall ist die Versionsnummer 8. Sie war bereits in den 1990er Jahren mit PIP von Paul Tsuchiya verbunden, einem der Kandidaten im damaligen Wettbewerb um den IPv4-Nachfolger. Auch wenn diese Zuordnung heute keine praktische Bedeutung mehr hat, ist IPv8 in der Geschichte der IETF keineswegs eine unbeschriebene Zahl.

Die Version 9 ist gleich mehrfach belegt. Dazu gehören TUBA, der berühmte Aprilscherz RFC 1606 und das sogenannte chinesische IPv9, das Anfang der 2000er Jahre als nationale Alternative zu IPv6 propagiert wurde. Selbst IPv10 existiert bereits als individueller Internet-Draft aus dem Jahr 2017, der schlicht argumentierte, dass IPv4 plus IPv6 zusammen eben zehn ergeben.

Thain verwendet damit eine Versionsnummer erneut, ohne auf ihre historische Vorbelegung einzugehen, und behandelt die Version, als stünde sie zur freien Verfügung. Streng genommen ist das nicht falsch: IANA hat die Reservierungen nach dem IPv6-Beschluss bereinigt. Aber die völlige Abwesenheit jeglicher historischen Einordnung im Entwurf ist ein bemerkenswertes Symptom.

Politisch aufgeladen

Dass ein technischer Einzelvorschlag überhaupt derart reflexhaft als zensurfreundlich gelesen wird, hat eine Vorgeschichte. Im September 2019 reichte Huawei, gemeinsam mit China Mobile, China Unicom und dem MIIT, bei der ITU-T einen Vorschlag mit dem Namen New IP ein. Im Rahmen der Focus-Group Network 2030 unter Richard Li präsentierte Huawei variable Adresslängen, semantische Adressen, benutzerdefinierte Header und ein berüchtigtes Shut-up Kommando auf Paketebene.

Die britische Financial Times zitierte anonyme ITU-Delegierte, die von einem enormen Kampf unter der Oberfläche sprachen. Seither ist jeder neue alternative IP-Stack-Vorschlag mit diesem Bezugsrahmen markiert, ob er aus Shenzhen, Shanghai oder eben Bermuda stammt.

Thains Entwurf adressiert keinerlei chinesische Agenda, doch seine zentralen Designentscheidungen wie OAuth2-Authentifizierung pro verwaltbarem Element, WHOIS8-Egress-Validierung jeder ausgehenden Verbindung, Zone-Server als Pflicht-Gateway, NIC-Firmware mit hardwareseitig erzwungenen Paketlimits, treffen exakt die Alarmnerven, die New IP hinterlassen hat.

Die Einschätzung, der Entwurf sei von Grund auf zensurfreundlich, ist kein Zufall, sondern spiegelt die Erfahrungen und Befürchtungen wider, die seit den Debatten um Huaweis New IP die Diskussion über die Zukunft des Internets prägen.

Die späte Pubertät von IPv6

Um sich den Fakten anzunähern, lohnt sich ein Blick auf den Zustand von IPv6 im April 2026. Googles Messung erreichte am 28. März 2026 erstmals einen Tages-Spitzenwert von 50,1 Prozent auf Google-Dienste weltweit; eine Schlagzeile, die mit kaum verhohlener Erleichterung gefeiert wurde. Der Durchschnitt pendelt seither zwischen 45 und 50 Prozent, je nach Wochentag. APNIC Labs misst rund 43 Prozent, Cloudflare etwa 40 Prozent bezogen auf HTTP-Requests.

Zu den Spitzenreitern zählen Frankreich, Indien und Saudi-Arabien; je nach Messmethode liegen sie deutlich über dem weltweiten Durchschnitt, dicht gefolgt von Indien, dessen hohe Werte wesentlich durch Reliance Jios früh eingeführte IPv6-only-Mobilfunknetze geprägt sind, sowie Deutschland.

Die USA überschreiten inzwischen die 50-Prozent-Marke, liegen im internationalen Vergleich jedoch nur im Mittelfeld. China wird im IPv6 Development Report 2025 mit 77 Prozent aktiven IPv6-Nutzern ausgewiesen; der dort genannte IPv6-Anteil am Gesamttraffic liegt jedoch nur bei 34 Prozent. Länder wie Sudan, Turkmenistan und viele Staaten in Afrika und Zentralasien erreichen weiterhin nur sehr geringe IPv6-Anteile von unter fünf Prozent.

Die IPv4-Knappheit hat sich dagegen deutlich entspannt. Große Blöcke ab /16 fielen bis Februar 2026 im Durchschnitt auf knapp unter zehn US-Dollar pro Adresse. Halter werfen Pools auf den Markt, weil sie fallende Preise antizipieren. Das Leasing-Geschäft bleibt stabil bei rund 0,50 US-Dollar pro IP und Monat. AWS berechnet seit Februar 2024 rund 44 Dollar pro Jahr pro öffentlicher IPv4-Adresse. Der wirtschaftliche Druck, auf IPv6 zu migrieren, ist real, aber nicht existenziell.

Geoff Huston von APNIC kommt in einer linearen Fortschreibung der aktuellen Entwicklung zu dem Ergebnis, dass der Übergang zu IPv6 erst gegen Ende des Jahres 2045 abgeschlossen wäre. Zugleich stellt er die Frage, ob das Internet nicht dauerhaft in einer Koexistenz aus IPv4 und IPv6 verharren könnte.

Die IETF-Gremien 6MAN und V6OPS beschäftigen sich mit Wartung, nicht mit Nachfolgern. Forschungsansätze wie SCION oder Named Data Networking haben den Testbed-Status bisher nicht verlassen und ersetzen IP in der Praxis nicht, während QUIC und HTTP/3 Performance-Probleme auf der Transportschicht lösen.

Der IETF-Prozess

Die entscheidende Einordnung, die in vielen Berichten untergeht, ist, dass ein Internet-Draft für sich nahezu keine Bedeutung hat. Jede Person kann einen solchen Entwurf einreichen. Die Prüfung durch das IETF-Sekretariat beschränkt sich im Wesentlichen auf formale Aspekte wie Struktur, vorgeschriebene Standardtexte und offensichtliche Verstöße gegen grundlegende Richtlinien. Anschließend erhält das Dokument einen offiziellen Dateinamen, ist für sechs Monate gültig und wird mit dem üblichen Hinweis versehen:

This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

Bis aus einem Internet-Draft ein offizieller RFC wird, ist es ein weiter Weg. Zunächst muss eine zuständige Working Group den Entwurf überhaupt aufgreifen und zu ihrem eigenen Arbeitsdokument machen. Danach folgen meist zahlreiche Überarbeitungen, öffentliche Diskussionsrunden und mehrere formale Prüfungen durch die Führungsgremien der IETF. Erst wenn dabei ein breiter Konsens entsteht und idealerweise bereits mehrere unabhängige Implementierungen existieren, wird das Dokument als RFC veröffentlicht.

Für Einzelentwürfe ohne Unterstützung einer Working Group ist dieser Weg in der Praxis nur selten erfolgreich. Aber es existieren Ausnahmen wie HTTP/1.0, TLS, OAuth 2.0, QUIC und JWT, welche als Individual Drafts starteten, bevor sie in Working Groups überführt wurden.

Sie brachten jedoch von Anfang an funktionierende Implementierungen, konkrete Einsatzszenarien und starke Unterstützung aus der Industrie und der Community mit. Fehlt eine solche technische und organisatorische Basis, verschwinden die meisten Vorschläge nach kurzer Zeit wieder, ohne jemals den Status eines Standards zu erreichen.

Fazit

Der Fall IPv8 zeigt in erster Linie, dass das IETF-System bewusst offen gestaltet ist. Diese Offenheit ist eine Stärke, bringt aber zwangsläufig auch Vorschläge hervor, die nie eine realistische Chance auf Standardisierung haben.

Der Entwurf ist kein realistischer Nachfolger für IPv6, sondern ein technisch fragwürdiger Alleingang. Er benennt zutreffend die schleppende IPv6-Migration, das Wachstum der BGP-Tabelle und die betriebliche Komplexität moderner Netze. Die Antwort darauf ist jedoch ein noch komplexerer Protokoll-Stack.

Die versprochene vollständige Rückwärtskompatibilität hält einer technischen Prüfung nicht stand. Bestehende Systeme werden Pakete mit der Versionsnummer 8 in aller Regel schlicht verwerfen. Wer IPv6 aus Kosten- und Trägheitsgründen bisher nicht eingeführt hat, wird einen noch aufwendigeren Nachfolger erst recht nicht ausrollen.

Dass der Entwurf dennoch für Aufmerksamkeit sorgt, liegt weniger an seiner technischen Substanz als an seinem Namen und am Zeitgeist. Die eigentliche Konsequenz ist unspektakulär, aber naheliegend: die konsequente Weiterverbreitung von IPv6.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Kommunikation von A nach B

Im Internet existieren eine Reihe von Diensten und Applikationen. Eine der wichtigsten Dienste, wenn nicht die Killerapplikation des Internets als es noch das ARPANET war, ist E-Mail. Zeit, ein wenig auf die Hintergründe dieses Systems zu blicken.

Einleitung

Zur Kommunikation existieren unterschiedlichste Dienste, welche das Internet nutzen, um Nachrichten von A nach B zu übermitteln. So sind im privaten Umfeld Messenger wie WhatsApp und Co nicht mehr wegzudenken. Daneben ist einer der wichtigsten Dienste für die Kommunikation die klassische E-Mail.

Der durchschnittliche Nutzer wird meist ein E-Mail-Programm auf dem Rechner, dem Mobilgerät oder ein Web-Mailer im Browser nutzen. Für den Nutzer ist es nicht wichtig wie das System funktioniert, allerdings lohnt es sich einen Blick hinter die Kulissen zu werfen und zu sehen, wie das System funktioniert und welche Herausforderungen der Betrieb eines E-Mail-Servers in der heutigen Zeit mit sich bringt.

Geschichte

Die Idee Nachrichten von A nach B zu verschicken gab es schon in der Frühzeit der Computertechnik, sogar noch früher, wenn elektrische Telegrafen einbezogen werden. So gab es ab dem Jahr 1962 mit dem Automatic Digital Network des US-Militärs bereits ein System, um Nachrichten an unterschiedlichste Standorte zu verteilen.

1968, mit der Erfindung des ARPANET, einem Forschungsprojekt im Auftrag des US-Militärs, wurden nicht nur die Grundlagen für unsere heutige Internetarchitektur geschaffen, sondern einige Jahre später, im Jahr 1971, die erste E-Mail versendet. Wobei hier der Terminus Network Mail genutzt wurde.

Für den Transfer der E-Mail wurde das Programm SNDMSG genutzt, welches es ermöglichte Nachrichten bzw. E-Mails von einem Nutzer zu einem anderen Nutzer auf dem gleichen System zu schicken.

Technisch war eine Mailbox nicht mehr als eine Datei, welche nur vom berechtigten Nutzer gelesen werden konnte, aber von unterschiedlichen Nutzern über SNDMSG geschrieben werden konnte.

Die Neuerung war nun die Idee, SNDMSG so zu erweitern, dass es E-Mails auch zu anderen Hosts senden konnte. Dafür wurde das At-Zeichen als Trennzeichen gewählt, um den eigentlichen Nutzer vom entsprechenden Host zu trennen. Daneben wurde READMAIL zum Lesen der Mails genutzt. Beide Programme, SNDMSG und READMAIL, wurden damals mit dem Betriebssystem TENEX genutzt.

Parallel zur ARPANET-Implementation und Vorstellung von Network Mail entstanden im Laufe der Zeit einige kommerzielle E-Mail-Systeme, sowie der X.400-Standard, welche bereitstanden, die Vorherrschaft der E-Mail-Systeme anzunehmen.

Bedingt durch die Öffnung des Internets gegenüber der kommerziellen Nutzung, genauer gesagt der Aufhebung der Restriktionen im Jahr 1995, mauserten sich SMTP, POP3 und IMAP zu den vorherrschenden Protokollen für das Senden und Abfragen von E-Mails.

Vorher war die kommerzielle Nutzung der damals im Rahmen des National Science Foundation Network-Programmes bereitgestellten Netzwerke durch entsprechende Richtlinien stark eingeschränkt. Grundsätzliche sollten diese Netzwerke hauptsächlich der Forschung und Lehre genutzt werden.

Auch wenn es heutzutage noch einige Bereiche gibt, in denen andere Standards genutzt werden, wie der X.400-Standard bei der Rufnummernportierung, hat sich der aktuelle E-Mail-Standard durchgesetzt.

Damit die Systeme trotzdem miteinander verbunden sein können, gab und gibt es unterschiedlichste Gateways, welche andere Netzwerke und E-Mail-Systeme miteinander verbinden.

Trennzeichen gesucht

Die Idee Nachrichten über Rechnergrenzen hinweg zu versenden führte zu dem Problem, dass diese Rechner adressiert werden müssen. Als Trennzeichen wurde das At-Zeichen (@) gewählt, welches nicht nur von der Bedeutung ideal war, sondern auch das Zeichen als solches war größtenteils ungenutzt. Damit war der Weg zu Adressen nach dem Schema nutzer@host frei.

Auf heutigen Tastaturen ist das At-Zeichen selbstverständlich

Bei der Auswahl des Zeichens war das Kriterium, dass das Zeichen auf den damaligen Tastaturen vorhanden war, aber auf keinen Fall ein Bestandteil eines Namens sein dürfte.

Der Erfinder der E-Mail, Ray Tomlinson sagte dazu selbst:

The primary reason was that it made sense. at signs didn’t appear in names so there would be no ambiguity about where the separation between login name and host name occurred. (Of course, this last notion is now refuted by the proliferation of products, services, slogans, etc. incorporating the at sign.) The at sign also had no significance in any editors that ran on TENEX. I was later reminded that the Multics time-sharing system used the at sign as its line-erase character. This caused a fair amount of grief in that community of users. Multics used IBM 2741 terminals which used EBCDIC character coding. They did not have a „control“ modifier key and didn’t have many (any?) non-printing characters beyond space, backspace, tab, and return. The designers of Multics were constrained to using printing characters for line-editing.

Während das Zeichen zuvor hauptsächlich zur Trennung von Mengen und Preisen genutzt wurde, hielt das Zeichen damit Stück für Stück Einzug in die moderne Welt und wurde praktisch zu einem unverkennbaren Zeichen der vernetzten Welt.

E-Mail, email, Mail?

Neben der eigentlichen Technik hinter dem E-Mail-System wurden im Laufe der Zeit auch andere Dinge, wie die Terminologie und Schreibweise, verhandelt. Während die Schreibweise im Deutschen als E-Mail definiert ist, sind im englischen Formen wie email, e-mail, E-mail, EMAIL und weitere Schreibweisen bekannt. Gebräuchlich ist hier meist die Schreibweise email bzw. e-mail. Bei RFCs hingegen wird im Author’s Adressblock die historisch bedingte Form EMail genutzt.

Dezentral wie das Netz

Das E-Mail-System an sich ist als dezentrales System für asynchrone Kommunikation konzipiert.

Das bedeutet, dass es nicht ein großer Betreiber existiert, welcher für alle E-Mail-Adressen der Welt zuständig ist. In der Theorie kann jeder Nutzer eines Rechners, welcher mit dem Internet verbunden ist, einen solchen E-Mail-Server betreiben.

Die Asynchronität definiert unter anderem dadurch, dass E-Mails abgeschickt werden können, ohne dass der Mail-Server des Empfängers erreichbar sein muss.

Systeme mit drei Buchstaben

Wer sich näher mit dem E-Mail-System auseinandersetzt, wird feststellen, dass es den E-Mail-Server an sich nicht gibt, sondern es sich um eine Ansammlung von Systemen, Diensten oder Programmen handelt.

Diese tragen überwiegend Abkürzungen bestehend aus drei Buchstaben wie MUA, MSA, MTA und MDA. Ordnung lässt sich in die Begriffe bringen, wenn der Weg einer E-Mail vom Sender zum Empfänger verfolgt wird.

Grundsätzlich geht es darum, eine E-Mail bzw. eine Nachricht von einem Rechner zu einem anderen Rechner zu transferieren und sie dort in der Mailbox des entsprechenden Nutzers zu hinterlegen.

Eine E-Mail wird in einem E-Mail-Client geschrieben

Wird eine E-Mail geschrieben, so geschieht das in einem E-Mail-Client, welcher im Kontext der Architektur des E-Mail-Systems als Mail User Agent (MUA) bezeichnet wird.

Manchmal wird das Wort Mail in den entsprechenden Begrifflichkeiten durch Message ersetzt. Je nach RFC findet sich eine unterschiedliche Terminologie in dieser. Die Begriffe werden dabei synonym verwendet. So bezeichnen beispielhaft Mail User Agent und Message User Agent das Gleiche.

Nachdem die Mail fertig geschrieben und ein Empfänger eingetragen wurde, kann die E-Mail versandt werden. Je nach Konfiguration sind hier unterschiedliche Wege denkbar.

Vom MUA zum MSA

So kann die entsprechende Mail per Simple Mail Protocol (SMTP) an den sogenannten Mail Submission Agent (MSA) gesendet werden. Gewöhnlich geschieht dies über den Port 587. Die Idee hinter dem Mail Submission Agent ist, dass dieser die E-Mails vom Endbenutzer entgegennimmt und diese an den Mail Transfer Agent (MTA) weiterleitet.

Damit stellt er in der Theorie die Schnittstelle zwischen dem Mail User Agent und dem Mail Transfer Agent dar. Im Gegensatz zum Mail Transfer Agent darf der Mail Submission Agent die eingelieferte E-Mail noch bearbeiten. So kann das E-Mail-Format überprüft und gegebenenfalls repariert sowie unvollständige E-Mail-Adressen vervollständigt werden. Dies ist z. B. dann der Fall, wenn die Domain des Absenders nicht voll qualifiziert angegeben wurde.

In der Theorie kann ein Mail User Agent ergo das E-Mail-Programm E-Mails auch direkt an einen Mail Transfer Agent senden. Allerdings nimmt dieser keine der obigen Prüfungen vor.

Mail Transfer Agent

Nachdem die E-Mail an den Mail Transfer Agent weitergeleitet wurde, entscheidet dieser, was mit der E-Mail geschieht. Im Grunde ist der MTA ist dafür zuständig, die E-Mail zum Ziel zu transportieren und die Nachricht schlussendlich an den Mail Delivery Agent (MDA) zu übergeben.

Eine Möglichkeit wie eine E-Mail zum Empfänger übertragen wird

Der Mail Transfer Agent führt in seiner Konfiguration eine Liste von Domains bzw. Hosts, für die er lokal zuständig ist. E-Mails, welche zu diesen Domains führen, werden direkt über den Mail Delivery Agent zugestellt.

Der MTA verändert die Mail beim Transfer im Grundsatz nicht, außer dass einige Headerfelder wie Received oder Return-Path, welche laut der entsprechenden RFC benötigt werden, hinzugefügt werden.

In der Frühzeit des E-Mail-Systems waren die meisten MTAs als sogenannte offene Relays (Open Relays) konfiguriert. Das bedeutete, dass sie von beliebigen Clients entsprechende E-Mails entgegennahmen und weiterleiten.

Diese Funktionalität konnte z. B. von Systemen genutzt werden, welche nur sporadisch am Netz waren und somit ihre E-Mail an ein Relay weiterleiten konnten, welches sich anschließend um die Zustellung kümmerte.

Dies führte schlussendlich zum Problem des Spams, da diese Relays missbraucht wurden, um Empfänger mit unerwünschten Mails zu belästigen. Infolgedessen finden sich heutzutage nur noch wenige offene Relays im Internet. Meist handelt es sich dabei um Fehlkonfigurationen. Ein MTA sollte in der heutigen Zeit nur nach einer entsprechenden Authentifizierung E-Mails entgegennehmen.

Auf Linux-Systemen wird gerne Postfix für diesen Teil des E-Mail-Systems genutzt. Je nach Konfiguration kann Postfix hier sowohl als MSA als auch als MTA verwendet werden.

Von MTA zu MTA

Ist die Empfänger-Domain nicht im Einflussbereich des Absender-MTAs, so wird die Mail an den zuständigen MTA gesendet.

Hierzu wird die Domain per DNS aufgelöst und es werden die entsprechenden MX-Records ausgewertet. In diesen sind die für die Domain zuständigen Mail Transfer Agents hinterlegt.

Ein solcher MX-Record könnte wie folgt aussehen:

	@		IN	MX	10 mail.example.org.

Es können pro Domain mehrere MX-Records angelegt werden. Der MTA, versucht diese nun nacheinander, sortiert nach ihrer Priorität, zu erreichen und die entsprechende E-Mail auf dem MTA der Empfänger-Domain einzuliefern.

Kann die E-Mail nach einer gewissen Zeit nicht eingeliefert werden oder erhält der MTA eine entsprechende Fehlermeldung, wird der ursprüngliche Absender der E-Mail informiert, damit dieser darauf reagieren kann.

Ist die Einlieferung der E-Mail hingegen erfolgreich gewesen, leitet der MTA der Empfänger-Domain die Mail an den Mail Delivery Agent weiter. Der MDA hat die Aufgabe, die E-Mails an die jeweiligen Nutzerkonten bzw. Mailboxen weiterzuleiten.

Beispiele für einen solchen MDA ist die Software Dovecot unter Linux. Daneben bietet Dovecot die Funktionalität mittels der Protokolle IMAP und POP3 auf die Mails der jeweiligen Nutzer über ein Netzwerk zuzugreifen.

Über diesen Weg können die E-Mails von den Nutzern vom Server geladen und gelesen werden. Damit landen die E-Mails beim Nutzer im Mail User Agent, dem E-Mail-Programm auf dem Endgerät des Empfängers.

Mailboxen

Die Mailboxen der Nutzer können auf dem Server in unterschiedlichen Formaten gespeichert werden. Die bekanntesten und am häufigsten genutzten Formate sind Maildir und Mbox.

Beim Speicherverfahren Maildir wird jede Mail in einer separaten Datei, innerhalb der durch Maildir festgelegten Verzeichnisstruktur, abgelegt. Beim Verfahren Mbox hingegen, befinden sich die Mails in einer großen Datei und werden in dieser Datei nacheinander gespeichert.

Anatomie einer E-Mail

Damit ist geklärt, wie eine Mail ihren Weg vom Absender zum Empfänger findet. Doch wie sieht eine solche E-Mail eigentlich aus? Dies definiert die RFC 5322. Eine simple E-Mail, gemäß der RFC, könnte wie folgt aussehen:

Return-Path: <>
Delivered-To: 
Received: by mail.example.org (Postfix, from userid 33)
        id 81FC87EE09FD; Sat,  1 Jan 2022 00:19:10 +0100 (CET)
From:  (Cron Daemon)
To: 
Subject: Update cronjob successfully
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
X-Cron-Env: 
Message-Id: <>
Date: Sat,  1 Jan 2022 00:19:10 +0100 (CET)

Update cronjob successfully executed.

Im Groben besteht eine E-Mail aus einem Header, in welchem sich unterschiedlichste Header-Felder befinden, welche Auskunft darüber geben, woher die E-Mail kam, wohin sie gehen soll und welche MTAs sie empfangen haben.

Daneben befinden sich weitere Informationen in der E-Mail, einige davon wie Subject, oder Date werden für die Anzeige der E-Mail im E-Mail-Programm herangezogen. Anschließend folgt der Message Body, in welchem die eigentliche Nachricht kodiert ist.

Da E-Mails an sich nur 7-Bit-ASCII-Zeichen unterstützen, müssen andere Zeichen und Typen von Inhalten wie Binärdateien erst umkodiert werden. Dazu wurden unter anderem die Multipurpose Internet Mail Extensions definiert, welche regeln, wie die entsprechenden Codierungen auszusehen haben.

Protokolle

Während sich bis zum Jahr 1980, innerhalb des ARPANET und dem dortigen E-Mail-System Protokolle wie SNDMSG und FTP mail hielten, haben sich im Laufe der Zeit einige Standardprotokolle herauskristallisiert, welche bis zur heutigen Zeit, mit einigen Erweiterungen genutzt werden.

Es handelt sich um die Protokolle SMTP, POP3 und IMAP. Während SMTP dem Transfer der E-Mail vom E-Mail-Client zum MSA bzw. dem Weiterversand von E-Mails von einem MTA zum nächsten dient, werden die Protokolle POP3 und IMAP zur Kommunikation des E-Mail-Servers mit dem E-Mail-Client genutzt.

SMTP

Das Simple Mail Transfer Protocol kurz SMTP nimmt beim E-Mail-System eine gehobene Stellung ein.

Während die E-Mails, welche auf dem eigenen E-Mail-Server empfangen wurden, theoretisch mit einem entsprechenden Shellzugriff direkt auf dem Server gelesen werden können, wird ein Protokoll benötigt, welches die E-Mails von einem Mail Transfer Agent zum nächsten MTA transportiert.

Hierfür wurde SMTP in der RFC 821 im August 1982 spezifiziert. Diese Version kam noch ohne Authentifizierung aus, sodass jedermann eine E-Mail bei einem MTA einliefern konnte, was im Laufe der Zeit zu einem Spam-Problem führte.

Deshalb wurde SMTP mit der RFC 1869 so erweitert, dass das Protokoll über einen Mechanismus verfügte, über welchen der Server den Client informieren konnte, über welche Service extensions der Server verfügt.

Dies ermöglichte es Authentifizierung und Verschlüsselungen über Erweiterungen wie STARTTLS durchzuführen und somit neben der Authentifizierung auch die Verschlüsselung zu gewährleisten.

Heutzutage sollten SMTP allerdings nicht mehr über STARTTLS, sondern direkt über TLS durchgeführt werden, da Technologien wie STARTTLS gegenüber Man-in-the-Middle-Angriffen anfällig sind.

POP3

Nachdem die E-Mails auf dem E-Mail-Server gelandet sind, wird ein Protokoll benötigt, um diese vonseiten des meist externen E-Mail-Clients wieder abzuholen.

Mit dem Post Office Protocol, welches in der aktuellen Version als POP3 abgekürzt wird, können die entsprechenden Mails vom E-Mail-Server heruntergeladen und vom Server gelöscht werden.

Mit POP4 sollte eine Weiterentwicklung des Protokolls verbunden sein, allerdings scheint diese seit 2003 nicht mehr gepflegt zu werden.

IMAP

Während sich POP3 gut dafür eignet, E-Mails vom Server zu holen, um die Postfächer im eigenen E-Mail-Client lokal zu verwalten, eignet sich das Internet Message Access Protocol kurz IMAP dazu, die entsprechenden E-Mails direkt auf dem Server zu verwalten.

IMAP unterstützt Funktionalitäten wie unterschiedliche Verzeichnisstrukturen oder die Benachrichtigung über neue E-Mails per Push-Verfahren.

Wie bei POP3 müssen auch bei IMAP zwei Protokolle unterstützt werden, da das Senden der Mails wiederum über SMTP erfolgt. Mit dem Simple Mail Access Protocol gab es Ansätze dies zu ändern, allerdings hat sich dieses bisher nicht durchgesetzt.

Ausfallsicherheit

Während wir heute daran gewöhnt sind, dass eine E-Mail meist innerhalb weniger Minuten beim Empfänger ankommt, war dies historisch gesehen nicht immer so. So konnte es schon einmal Tage dauern, bis eine entsprechende E-Mail schlussendlich beim Empfänger ankam.

Dies war unter anderem dadurch bedingt, dass nicht alle E-Mail-Server immer eine permanente Verbindung zum Internet hatten und es auch vorkommen konnte, dass Server für einige Zeit nicht verfügbar waren.

Das zeigt aber auch auf, wie resilient das E-Mail-System gestaltet wurde. Wenn ein MTA auf Empfängerseite nicht verfügbar ist, versuchen die sendenden MTAs die E-Mail später zuzustellen. Meist wird eine E-Mail erst nach einiger Zeit z. B. 48 Stunden als unzustellbar angesehen und der Absender entsprechend informiert.

Das bedeutet, wenn der eigene E-Mail-Server einmal ausfällt, so ist dies im ersten Moment kein dramatisches Ereignis, weil im Idealfall trotzdem alle E-Mails zugestellt werden.

Einen E-Mail-Server aufsetzen

Wer seine Domain bei einem Webhoster untergestellt hat, bekommt meist einen entsprechenden, vom Anbieter gewarteten E-Mail-Server dazu.

Interessanter wird es, wenn ein solcher E-Mail-Server selbst aufgesetzt werden soll. In einem solchen Fall muss ein MTA und MDA ausgewählt werden. Unter Linux ist eine beliebte Kombination für diese Funktionalitäten Postfix und Dovecot.

Grundsätzlich ist der Markt an Server-Anwendungen breit gestreut. Neben den Linux-Varianten und Servern wie Postfix und Dovecot existieren auch proprietäre Lösungen wie der Microsoft Exchange Server.

Nachdem die passende Lösung gewählt wurde, sollte diese für den jeweiligen Anwendungsfall konfiguriert oder entsprechend vorkonfektionierte Pakete genutzt werden.

Betrieb des Servers

Ist der E-Mail-Server aufgesetzt, fangen die eigentlichen Probleme an. Dies fängt damit an, dass es praktisch unmöglich ist, einen E-Mail-Server zu Hause zu betreiben. Die Einlieferung von E-Mails von Servern, welche in dynamischen DSL-IP-Adressbereichen unterwegs sind, wird von den meisten Betreibern von E-Mail-Servern unterbunden, meist um Spam zu verhindern.

Damit bleibt als Lösung der Betrieb eines Servers in einem Rechenzentrum, mit entsprechend fixer IP-Adressen oder entsprechenden Tarifen im gewerblichen Umfeld.

Ist der E-Mail-Server eingerichtet, der MX-Record korrekt gesetzt und sind die entsprechenden Nutzer angelegt, kann der Nutzer in der Theorie Mails senden und empfangen.

Neben dem Setzen des MX-Records ist es mittlerweile auch hilfreich, die DNS-Records für die automatische Erkennung durch E-Mail-Clients zu konfigurieren. Geregelt wird das Verfahren in der RFC 6186. Dies ermöglicht es den Clients, die Konfiguration für den E-Mail-Server schnell und unkompliziert vorzunehmen.

In der Praxis ist das erfolgreiche Senden von E-Mails eine kleine Herausforderung. So müssen entsprechende PTR-Records für die Auflösung der IP-Adresse zur entsprechenden Domain hinterlegt werden.

Andere E-Mail-Server überprüfen, ob der Name der IP-Adresse (Reverse DNS) zum eigenen E-Mail-Server passt. Wird etwa die IP-Adresse 192.168.10.1 genutzt und deren Reverse DNS-Name lau­tet mail.example.com, so muss auch der Host­name mail.example.com in der Konfiguration des Mailservers dementsprechend konfiguriert sein.

Sendet der Server die E-Mails auch per IPv6, so muss überprüft werden, dass ein entsprechender PTR-Record für die Adresse gesetzt ist, ansonsten kann es zu solchen Meldungen im E-Mail-Verkehr kommen:

host mail.example.com[2001:db8:a0b:abf0::1]
said: 550-Inconsistent/Missing DNS PTR record (RFC 1912 2.1)
(example.org) 550 [2001:db8:a0b:12f0::1]:34865 (in reply to RCPT TO command)

Selbst wenn der Eintrag zur Auflösung der IP-Adresse (Reverse DNS) korrekt gesetzt ist, kann es passieren, dass bei der Nutzung von IPv6 diese Meldung erscheint. Hintergrund ist meist, dass der entsprechende Server ein IPv6-Subnetz erhält und z. B. Postfix dann eine beliebige Adresse aus diesem Subnetz zum Senden benutzt. Hier bietet es sich an, die entsprechende Interface-Adresse für den Server fest zu definieren.

E-Mails sinnvoll zuzustellen ist insbesondere bei größeren Anbietern wie Gmail problematisch, weil eine Reihe von Voraussetzungen erfüllt sein müssen.

Hier ist es neben den normalen Maßnahmen wie dem korrekten Setzen der DNS-Einträge (Forward und Reverse), meist auch notwendig Verfahren wie SPF, DKIM und DMARC zu implementieren, welche die Komplexität für den entsprechenden E-Mail-Server steigen lassen.

SPF

Mit dem Sender Policy Framework (SPF), wurde ein Verfahren geschaffen, welches sicherstellen sollte, dass E-Mails mit bestimmten Absendern nur von berechtigten E-Mail-Server versendet werden können.

SPF wird auf der Empfängerseite geprüft

Dazu wird bei SPF im DNS eine entsprechende Konfiguration hinterlegt, welche festlegt, welche Server berechtigt sind, für die Absender-Domain E-Mails zu versenden. Die entsprechend notwendigen DNS-Records können über unterschiedlichste Tools erzeugt werden, z. B. über die Webseite spf-record.de.

DKIM

Bei DomainKeys Identified Mail (DKIM) wird die jeweilige E-Mail um eine Signatur ergänzt, über welche der empfangende MTA feststellen kann, ob die E-Mail wirklich vom MTA der Absender-Domain stammt.

Dazu wird über einen im DNS hinterlegten öffentlichen Schlüssel für die Absender-Domain überprüft, ob die Signatur in der E-Mail valide ist.

DMARC

Aufbauend auf SPF und DKIM existiert mit Domain-based Message Authentication, Reporting and Conformance (DMARC) eine Spezifikation, mit welcher festgelegt wird, wie mit entsprechenden E-Mails, welche durch die SPF- und DKIM-Prüfung durchgefallen sind, reagiert werden soll.

Auch hier werden DNS-Records der Absender-Domain genutzt, um entsprechende Informationen für die Richtlinie zu hinterlegen.

Eine Besonderheit bei DMARC ist, dass der im DNS-Record hinterlegte DMARC-Admin über fehlgeschlagene DMARC-Prüfungen informiert werden kann und somit erfährt, dass die entsprechende Domain für Spam missbraucht wird.

Klein anfangen

Bei kleinen E-Mail-Servern, mit geringen Volumen an E-Mails, reicht es meist aus SPF zu aktivieren. Spätestens bei der Nutzung von IPv6 müssen einige Maßnahmen wie SPF eingerichtet werden, um E-Mails sicher versenden können. Andernfalls kann es vorkommen, dass solche E-Mails abgelehnt werden.

Auch ist es nicht ratsam sofort mit großen E-Mail-Volumina auf die Server von Google zu feuern, hier wird ein langsames Ansteigen der Last über einen längeren Zeitraum bevorzugt, um nicht von eventuellen Anti-Spam-Maßnahmen betroffen zu sein.

Dann gibt es auch noch speziellere Fälle, wie bei T-Online, in deren Dokumentation sich folgender Abschnitt findet:

Insbesondere empfehlen wir, den Hostnamen so zu wählen, dass seine Nutzung als Mailserver für Außenstehende erkennbar ist (z. B. mail.example.com), und sicherzustellen, dass die Domain zu einer Website führt, die eine Anbieterkennzeichnung mit sämtlichen Kontaktdaten beinhaltet.

Bei solchen Regeln ist es damit praktisch unmöglich einen reinen E-Mail-Server zu konfigurieren, da zumindest ein Webserver mit dem Impressum vorhanden sein muss. Ansonsten erhält der Betreiber des E-Mail-Servers entsprechende Meldungen im Log:

Dec  6 19:07:26 host42 postfix/smtp[3017216]: ED2DA7EE0104: to=<>, relay=mx00.t-online.de[194.25.134.8]:25, delay=0.33, delays=0.16/0.02/0.14/0, dsn=4.0.0, status=deferred (host mx00.t-online.de[194.25.134.8] refused to talk to me: 554 IP=192.168.9.1 - A problem occurred. (Ask your postmaster for help or to contact  to clarify.))

Spam, Spam, Spam

Monty Python schenkte uns nicht nur Silly Walks, sondern auch Spam. Der berühmte Sketch führte schlussendlich dazu, dass wir ungewollte E-Mails als Spam bezeichnen. Das Problem selbst wurde relativ früh erkannt und in die RFC 706, welche den schönen Titel On the Junk Mail Problem trägt, gegossen.

Spam ist in unserer heutigen Zeit allgegenwärtig und wird leider massenhaft versendet. Ohne zumindest minimale Maßnahmen, um Spam zu unterdrücken, sollte ein E-Mail-Server nicht betrieben werden. Hier muss auch immer die Abwägung getroffen werden zwischen der Filterung unerwünschter Mails und dem Abweisen von legitimen Mails, welche fälschlicherweise als Spam erkannt worden sind.

Greylisting

Eine der einfachsten und effektivsten Maßnahmen gegen Spam ist das sogenannte Greylisting. Beim Greylisting wird eine Mail von einem unbekannten Absender im ersten Schritt nicht angenommen und stattdessen ein technischer Fehler kommuniziert.

Sep  4 09:12:26 lexa postfix/smtpd[2761177]: NOQUEUE: reject: RCPT from unknown[213.209.159.56]: 450 4.2.0 <>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/example.org.html; from=<> to=<> proto=ESMTP helo=

Standardkonforme E-Mail-Server senden eine solch zurückgewiesene E-Mail nach einer Wartezeit noch einmal. Ist die eingestellte Greylisting-Zeit abgelaufen, wird die E-Mail anschließend angenommen.

Bei einer Spamnachricht, welche an viele Millionen Empfänger gesendet wird, findet dieses abermaliges Versenden der E-Mail in den meisten Fällen nicht statt. Damit kann mittels Greylisting ein Großteil von Spam-E-Mails gefahrlos aussortiert werden.

Problematisch wird Greylisting dann, wenn z. B. Zwei-Faktor-Authentifizierungscodes empfangen werden sollen, welche nur eine gewisse Zeit gültig sind und durch die Verzögerung beim Greylisting ihre Gültigkeit verlieren.

Weitere Filter

Neben dem Greylisting, gibt es eine Reihe von kleineren Überprüfungen, welche vorgenommen werden können, bevor eine E-Mail angenommen wird. Je nach eingesetzter Software können diese Direkten aktiviert werden und somit E-Mails, welche den Direktiven widersprechen, abzuweisen.

So existiert unter Postfix z. B. die Direktive reject_unknown_sender_domain. Diese Direktive weist E-Mails zurück, welche Adressen nutzen, für welche kein MX- oder A-Record vergeben wurde. Dies ist dann der Fall, wenn entsprechender Spam von Adressen versendet wird, welche in Wirklichkeit nicht existieren oder von Servern kommen, welche nicht als E-Mail-Server konfiguriert sind.

In einer Postfix-Konfiguration werden diese Direktiven nacheinander abgearbeitet:

smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  defer_unauth_destination
  reject_unknown_sender_domain
  reject_unknown_reverse_client_hostname
  reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
  reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99]
  reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99]
  reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99]
  warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255]
  check_policy_service inet:127.0.0.1:10023

Durch diese Direktiven, welche gewisse Prüfungen auf Standardkonformität durchführen, wird idealerweise ein Großteil des Spams abgewiesen.

DNS-based blocklists

Daneben sind zur Bekämpfung von Spam auch DNS basierte Blocklisten in Gebrauch. Bei einer solchen Liste wird die IP-Adresse des Senders per DNS gegenüber dem Anbieter der Blockliste aufgelöst. Über den Rückgabecode kann damit ermittelt werden, ob das entsprechende sendende System als Spam eingestuft wird und die entsprechende Mail zurückgewiesen werden.

Auf dem Markt sind einige größere Listen verfügbar, z. B. von Spamhaus. Für den eigenen E-Mail-Server, sollte hier eine sinnvolle Abwägung getroffen werden, welche Liste(n) zur Prüfung hinterlegt werden sollen, da diese Listen im schlimmsten Fall darüber entscheiden ob eine E-Mail abgewiesen wird.

E-Mail-Server goes Cloud

Wer diesen Aufwand nicht treiben möchte, kann seine eigene Domain mit einem E-Mail-Server aus der Cloud versorgen. Unter anderem Google unterstützt dies.

So kann mit Google Workspace eine eigene Domain für die Nutzung von Gmail eingerichtet werden. Damit wird das E-Mail-System von Google benutzt und in der Theorie hält sich der Wartungs- und Verwaltungsaufwand in Grenzen.

Problematisch ist allerdings, dass sich in eine entsprechende Abhängigkeit begeben wird und auch datenschutzrechtliche Aspekte eine Rolle spielen, was z. B. den Transfer von Daten in das Nicht-EU-Ausland angeht.

Technisch realisiert wird dies so, dass die entsprechenden MX-Records für die eigene Domain auf die E-Mail-Server von Google zeigen und somit die offiziellen E-Mail-Server für die Domain sind.

Rechtliche und weitere Anforderungen

Neben den technischen Anforderungen kommen je nach Größe des E-Mail-Servers noch weitere rechtliche Anforderungen hinzu. So müssen ab einer bestimmten Nutzeranzahl unter Umständen Abhörschnittstellen eingerichtet werden, was sich aus der Telekommunikations-Überwachungsverordnung ergibt.

Auch ist es sinnvoll bestimmte E-Mail-Adressen, wie sie in der RFC 2142 definiert werden, bereitzuhalten. Daneben sollten auch Prozesse eingerichtet werden, um Anfragen an diese E-Mail-Adressen, wie. z. B. Abuse-Adressen, zu bearbeiten.

Re­sü­mee

Auch wenn der Betrieb eines E-Mail-Servers mit gewissen Anforderungen verbunden ist, bietet er durchaus Vorteile. So können private Daten auf der eigenen Infrastruktur gehalten und verarbeitet werden und es löst Abhängigkeiten von großen Infrastrukturanbietern.

Außerdem trägt ein solcher Server zum Grundgedanken des E-Mail-Systems bei, dass es sich um ein dezentrales System handelt.

Wer einen E-Mail-Server für private Zwecken einrichten möchte, kann sich z. B. der Top-Level-Domain .email annähern, mit welcher sich angenehm kurze E-Mail-Adressen für die eigene Familie (z. B. ) realisieren lassen.

Auch wenn heutzutage die firmeninterne Kommunikation in vielen Fällen über andere Systeme wie Slack oder Teams läuft und wir in persönlichen Kontakten meist auf Messenger à la WhatsApp oder Signal setzen, wird E-Mail, auch wenn sie ein in die Jahre gekommenes Medium ist, uns in der Zukunft begleiten.

Dieser Artikel erschien ursprünglich auf Golem.de und ist hier in einer alternativen Variante zu finden.

Freifunk – eine Einführung

Bedingt durch unseren Hackerspace, den wir in Neubrandenburg betreiben, habe ich mich in letzter Zeit etwas intensiver mit dem Thema Freifunk beschäftigt.

Der Hackerspace in der Stadtmauer

Es sollte ein Router an das Freifunknetz angeschlossen werden. Die Vorstellungen, welche mir davon im Kopf schwebten, war am Anfang etwas diffus. Glücklicherweise gibt es den Verein Förderverein Freie Netzwerke e. V. – welcher einem mit Rat und Tat zur Seite steht.

Die Freifunk-Community

So wird die offizielle Webseite, freifunk.net, besucht und dort finden sich folgende Punkte unter anderem die Punkte Worum geht’s? und Wie mache ich mit? – schon mal ein guter Einstieg. In früheren Jahren fand sich auf der Webseite dann noch der Satz:

Wir regeln den Rest.

Ganz so einfach ist es allerdings nicht. Auf der Suche nach Informationen ist die Webseite ein guter Anlaufpunkt, im Worum geht’s?-Video klingt das Ganze noch einfach und blumig.

Aktivieren Sie JavaScript um das Video zu sehen.
Video-Link: https://vimeo.com/64814620

Für etwas Klarheit sollte sich die Organisationsstruktur der Freifunk-Community angeschaut werden. Zum einen existiert der Förderverein Freie Netzwerke e. V. Dieser betreibt unter anderem die Webseite freifunk.net. Auf der Webseite wird die Tätigkeit des Vereines wie folgt beschrieben:

Aufgabe des Fördervereins Freie Netzwerke e.V. ist die Förderung der Bildung und Kultur bezüglich kabelloser und kabelgebundener Computernetzwerke, die der Allgemeinheit zugänglich sind (sogenannte freie Netzwerke). Zu diesem Zweck betreibt der Verein die Internetplattform freifunk.net und fördert darüber hinaus diverse Aktivitäten und initiiert Projekte, die den nachfolgenden Zwecken dienen:

* Information über freie Netzwerke, insbesondere durch das Internet sowie durch Vorträge, Veranstaltungen, Vorführungen und Publikationen
* Bereitstellung von Know-How über Technik und Anwendung freier Netzwerke
* Information über gesellschaftliche, kulturelle, gesundheitliche und rechtliche Auswirkungen freier Netzwerke
* Förderung der Kontakte und des Austauschs mit Menschen und Organisationen im In- und Ausland, die im Bereich der freien Netzwerke tätig sind
* Förderung und Unterstützung von Projekten und Initiativen, die in ähnlichen Bereichen tätig sind

Neben der Freifunk-Webseite betreibt der Verein unter anderem auch den Blog freifunkstattangst.de, welcher sich mit der Frage der Störerhaftung beschäftigt.

Die lokalen Freifunk-Communitys, z. B. in Berlin, Hamburg oder auch Bielefeld, möchten an ihren Standorten dezentrale Mesh-Netzwerke aufbauen. Mittlerweile existieren über 400 solcher lokalen Communitys im deutschsprachigen Raum.

Gratis-WLAN mit Internetanbindung

Dabei wird Freifunk gerne auf die Formel Gratis-WLAN mit Internetanbindung reduziert. Bei einem genaueren Blick auf Freifunk ist dies aber nur ein netter Nebeneffekt. Genauer wird das Ganze in der Vision erklärt. Dort wird eine zentrale Frage an den Interessenten gestellt:

Wie wäre es, wenn auch online jeder mit jedem kommunizieren könnte, ohne eine Firma bei der man sich anmelden müsste?

Diese Frage beschreibt sehr gut, warum die Freifunker das tun, was sie tun. Auch das Selbstverständnis der Freifunker wird dort beschrieben:

Wir verstehen frei als

* öffentlich und anonym zugänglich
* nicht kommerziell und unzensiert
* im Besitz einer Gemeinschaft und dezentral organisiert

Die Qual der Wahl

Doch wie fängt der Interessierte an? Neben der rechtlichen Form (z. B. ein gemeinnütziger Verein) welche sich die lokale Community geben kann, gibt es viel profanere Probleme, welche es zu lösen gilt.

Ein Freifunk-Router (CC-BY / Jens Ohlig)

Ein Freifunk-Router (Jens Ohlig, Freifunk router, CC BY 3.0)

Bevor sich mit der Hardware beschäftigt werden kann, muss sich erst mit der Software – in diesem Fall der Firmware – beschäftigt werden. Schließlich muss eine kompatible Firmware für die gewünschte Hardware gefunden werden. Die Anzahl der Firmware-Varianten ist insbesondere für Einsteiger erst einmal unüberschaubar.

Es fühlt sich so an als ob jede lokale Community ihre eigene Firmware-Version nutzt. Als Einsteiger kommt der Wunsch auf hier mehr an die Hand genommen zu werden.

Fledermäuse im Mesh-Netzwerk

Die unterschiedlichen Firmwares unterscheiden sich nicht nur durch die unterschiedlichen Features, sondern auch durch die verwendeten Routing-Protokolle zum Aufbau eines Mesh-Netzwerkes. So gibt es Firmware welche das Optimized Link State Routing Protocol, kurz OLSR, nutzen, andere wiederum nutzen das Better Approach To Mobile Adhoc Networking-Protokoll (B.A.T.M.A.N.). Bei der Gründung einer neuen Community muss sich also überlegt werden, welches Routing-Protokoll eingesetzt werden soll. Schließlich sollten die anderen Router der Community mit demselben Protokoll betrieben werden.

OLSR, wurde in der RFC 3626 spezifiziert und ist ein Protokoll, bei dem jedem Knoten die komplette Topologie des Netzes bekannt ist. Damit handelt es sich um ein Link-State-Routing-Protokoll, welche sich dadurch auszeichnen, dass der Router eine Datenbank mit den entsprechenden Informationen über die Topologie aufbaut. Bei OLSR führt dies dazu, dass relativ viel Bandbreite und Rechenleistung zur Berechnung der Pfade im vermeshten Netzwerk benötigt wird.

Das Protokoll B.A.T.M.A.N. hingegen kennt nicht mehr die komplette Topologie des Netzwerkes. Stattdessen informiert jedes Gerät seine Nachbarn darüber, dass es existiert. Diese Nachbarn wiederum informieren ihre Nachbarn. Beim Routing geht es nun darum das Paket in die richtige Richtung zu schicken, ohne die komplette Route vorher zu kennen.

Mit der Weiterentwicklung B.A.T.M.A.N. Advanced, welches auf der zweiten Schicht im OSI-Modell, dem Data Link Layer arbeitet, können die entsprechenden Geräte sich mit dem vermeshten Netz verbinden und sind frei in der Wahl ihrer Protokolle auf dem OSI-Layer 3. Es spielt für B.A.T.M.A.N. Advanced keine Rolle mehr, ob auf diesem OSI-Layer DHCP, IPv4, IPv6 oder andere Protokolle genutzt werden. Seit mittlerweile über zehn Jahren befindet sich die Unterstützung für dieses Protokolls, in Form Kernel-Moduls, im offiziellen Linux-Kernel.

OpenWrt

Die Basis der meisten, wenn nicht aller Freifunk-Firmwares ist OpenWrt. Dabei handelt es sich um eine auf Linux basierende Distribution für kleinere Embedded Devices – welche vorwiegend für Router genutzt wird.

Historisch basiert OpenWrt auf der Firmware der Router-Serie WRT54G von Linksys. Der dort genutzte Linux-Kernel ist unter der GNU General Public License lizenziert und damit muss der Quellcode für die Firmware ebenfalls mit ausgeliefert werden.

Nach einigen Appellen führte dies dazu, dass Linksys, den entsprechenden Quellcode freigab. Daneben wurde im Lichte dieser Ereignisse das Projekt gpl-violations.org, welches sich der Durchsetzung der GPL verschrieb, durch Harald Welte gegründet.

Auf der Suche nach der passenden Hardware sollte sichergestellt werden, dass diese von OpenWrt unterstützt wird. Dazu gibt es in der OpenWrt-Wiki eine Table of Hardware und einen Einkaufsratgeber. Wichtig ist hier, dass das beste Gerät nicht existiert, es sollte den gewünschten Ansprüchen entsprechen und dem Einsatzzweck genügen.

Nach der Geräteauswahl, erfolgt die Auswahl der Firmware, schließlich muss der Router mit einer passenden Software bespielt werden. Auch hier ist die Auswahl wieder einmal unübersichtlich. Soll das Routing-Protokoll OSLR genutzt werden, so kann vom Meshkit eine passende Freifunk-Firmware generiert werden. Allerdings werden hier nicht alle OpenWrt-Plattformen unterstützt, sodass je nach verwendeter Hardware Meshkit ausscheidet.

meshkit.freifunk.net

Bei der Nutzung des moderneren B.A.T.M.A.N. bzw. B.A.T.M.A.N. Advance-Protokolls, kann auf Gluon gesetzt werden. Dabei handelt es sich um ein modulares Framework mit welchem eine entsprechende Freifunk-Firmware auf der Basis von OpenWrt erzeugt werden kann. Über die Hälfte der Freifunk-Communitys setzt auf diese Lösung.

Bei Gluon wird anhand einiger Konfigurationsdateien ein passendes Image erzeugt. Das Gluon-Image verfügt auch über eine Funktion für automatische Updates, mit welcher die entsprechenden Geräte mit neuen Versionen bespielt werden können.

Rechtliche Rahmenbedingungen

Nach der Installation des Images auf der gewünschten Hardware ist, ist der Freifunk-Router fertiggestellt. Überspitzt ließe sich sagen, dass die Probleme damit anfangen. Auf technischer Seite gibt es bei der Standardkonfiguration das Problem, dass die Luftschnittstelle unverschlüsselt ist, was unschön ist. Ein anderes Problem ist die Haftung, womit wir bei der rechtlichen Seite von Freifunk landen.

Die Freifunk-Geräte senden ihren Traffic zu einem in der Firmware eingestellten Gateway. Damit haben die Aufsteller der Router keine Probleme. Im Gateway wird der Traffic dann in das Internet überführt. Hier wird es problematisch. Natürlich haftet in der Theorie niemand für die Straftaten anderer. Allerdings ist der Betreiber des Gateways der erste Ansprechpartner, wenn etwas schiefgeht – und im schlimmsten Fall hat dieser erst einmal eine Menge Stress mit der Judikative und der Exekutive – bis dort bemerkt wird, dass jemand anders gesucht wird. Glück dem, der sich auf das Providerprivileg berufen kann.

Als Lösung ließe sich hier unter anderem der Gateway-Traffic über einen VPN-Zugang ins Internet routen, damit das eigene Freifunk-Netzwerk unbeschwerter in Betrieb genommen werden kann. Dies ist bei den meisten Freifunk-Communitys der Standard.

Mitte 2017 beschloss der Bundestag eine Änderung des Te­le­me­di­en­ge­set­zes, in welchem die oft kritisierte Störerhaftung abgeschafft wurde. Der entsprechende Paragraph 8 des TMG enthält nun unter anderem folgenden Punkt:

(1) Diensteanbieter sind für fremde Informationen, die sie in einem Kommunikationsnetz übermitteln oder zu denen sie den Zugang zur Nutzung vermitteln, nicht verantwortlich, sofern sie

1. die Übermittlung nicht veranlasst,
2. den Adressaten der übermittelten Informationen nicht ausgewählt und
3. die übermittelten Informationen nicht ausgewählt oder verändert haben.

² Sofern diese Diensteanbieter nicht verantwortlich sind, können sie insbesondere nicht wegen einer rechtswidrigen Handlung eines Nutzers auf Schadensersatz oder Beseitigung oder Unterlassung einer Rechtsverletzung in Anspruch genommen werden; dasselbe gilt hinsichtlich aller Kosten für die Geltendmachung und Durchsetzung dieser Ansprüche. ³ Die Sätze 1 und 2 finden keine Anwendung, wenn der Diensteanbieter absichtlich mit einem Nutzer seines Dienstes zusammenarbeitet, um rechtswidrige Handlungen zu begehen.

Damit wurde auch im Freifunk-Bereich wesentlich mehr Rechtssicherheit geschaffen, sodass der Betrieb solcher offener Netzwerke wesentlich angenehmer geworden ist.

Resümee

Die Gründung einer lokalen Gruppe ist mit einigen Herausforderungen verbunden, während die Integration eigener Router in bestehende Communitys wesentlich einfacher ist. Für unseren Hackerspace haben wir beschlossen, es auf einen späteren Zeitpunkt zu vertagen, da wir unsere Energie erst einmal in andere Themen gesteckt haben.

Dieser Artikel erschien ursprünglich 2014 unter dem Titel Freifunk für Dummies und wurde anschließend für eine Veröffentlichung bei Golem.de aktualisiert.

JSON-Validator und Formatierer

Der JavaScript Object Notation, kurz JSON, sind viele Entwickler sicherlich schon einmal über den Weg gelaufen. Bei der Arbeit mit JSON-Daten tritt ab und an der Fall auf das Daten für einen Test validiert oder sinnvoll formatiert werden sollen.

Der JSON Formatter & Validator von Curious Concept

Im Web existieren unterschiedlichste JSON-Validatoren und Formatierer, allerdings mit eher schwankender Qualität. Einer der Validatoren, welcher heraussticht ist der JSON Formatter & Validator von Curious Concept. Er kann JSON-Daten nach den unterschiedlichsten Standards (RFC 8259, RFC 7159, RFC 4627 und ECMA-404) validieren und anhand unterschiedlichster Templates formatieren. Zu finden ist der Validator unter jsonformatter.curiousconcept.com.

Maximale URL-Länge bei HTTP

Der Uniform Resource Locator, oder in der Kurzform die URL, wird sicherlich jedem schon begegnet sein. Die URL setzt sich aus einem Schema und einem für das Schema spezifischen Part zusammen. Getrennt werden die beiden Bestandteile durch einen Doppelpunkt. Bei HTTP wäre die Angabe des Schemas (http) und dem anschließenden spezifischen Teil mit dem Host, eventuellen Informationen über den Port, Kennwörter und ähnliches und anschließend der Pfad zur gewünschten Ressource. Interessant ist allerdings die Frage, wie lang darf eine solche URL sein? Kurze URLs wie:

http://api.example.com

machen keinerlei Probleme. In der RFC 2616 finden sich erste Anhaltspunkte dazu. Die RFC trägt den Namen Hypertext Transfer Protocol — HTTP/1.1 und definiert eben dieses Protokoll. Im Abschnitt 3.2, der sich um Uniform Resource Identifiers dreht, findet sich im Unterpunkt 3.2.1 folgender Abschnitt:

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Aus diesem Abschnitt ergibt sich das URLs so lang wie benötigt sein dürfen und das HTTP-Protokoll keinerlei Beschränkung vornimmt. Sollte der Server eine lange URL nicht verarbeiten können, so soll dieser mit dem Statuscode 414 (URI Too Long) antworten. Gleich danach finden sich ein weiterer Hinweis in der RFC:

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

Dort wird darauf hingewiesen das es Probleme geben kann, wenn die URL länger als 255 Byte ist. Je nach Kodierung und Sprache (wie z.B. Deutsch oder Japanisch), lassen sich eine unterschiedliche Menge an Informationen in diesen 255 Byte kodieren. Allerdings wurde die RFC 2616 durch die RFC 7230 für obsolet erklärt. In dieser RFC findet sich folgender Absatz:

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

Mit diesem Absatz wird definiert das HTTP-Clients und Server eine Mindestlänge von 8000 Byte unterstützen sollen. In der Praxis stellt sich nun die Frage was wirklich funktioniert. Es existieren durchaus längere URLs, z.B. sogenannte Data-URLs, allerdings sind dies keine HTTP-URLs, sondern definierten ein eigenes Schema. Daneben existieren alte Untersuchungen zu dem Thema. Unabhängig von der theoretischen Machbarkeit existieren weitere Kriterien, wie die maximale Länge die von Suchmaschinen indiziert werden. Hier schwanken die Zahlen zwischen knapp 1800 Byte bis zu 2048 Byte.

Damit lässt sich die Frage nach der maximalen URL-Länge nicht pauschal beantworten. Mit aktueller Software auf Server- und Client-Seite, sollten 1024 Byte für die URL kein Problem sein. Längere URLs sollten mit Vorsicht genossen werden und ihre Sinnhaftigkeit noch einmal hinterfragt werden.