Zusammenfassung

  • RFC 3316 beschrieb GPRS und UMTS als IPv6-Punkt-zu-Punkt-Verbindungen: Nach der Router-Erkennung war der Standardrouter der einzige Nachbar des Hosts; Link-Layer-Adressen mussten nicht aufgelöst werden.
  • Damit entfiel die Adressauflösung, nicht aber die Frage, ob der Router noch erreichbar war. Neighbor Unreachability Detection (NUD) blieb relevant; TCP-, RTCP- oder SIP-Rückmeldungen konnten unter bestimmten Bedingungen einen begrenzten Nachweis für Kommunikation in beide Richtungen liefern und überflüssige Prüfungen vermeiden.

Analyse

Als die IETF RFC 3316 2003 veröffentlichte, beschränkte schon der Titel den Anspruch sorgfältig auf „einige“ Mobilfunk-Hosts der zweiten und dritten Generation. Das Informational-Dokument richtete sich an Entwickler von Hosts für GPRS und bestimmte UMTS-Releases. Es war weder ein neuer IPv6-Standard noch eine universelle Checkliste für jedes Funkverfahren, jeden Laptop oder jeden Mobilfunkrouter. Die Einleitung warnte ausdrücklich davor, die Empfehlungen ohne detaillierte Analyse auf andere Mobilfunktypen zu übertragen.

Diese Grenze war wichtig, weil die üblichen IPv6-Verfahren auf ein anderes Link-Modell trafen. In einem gemeinsam genutzten Ethernet muss ein Host unter Umständen die IPv6-Adresse eines Nachbarn erst in eine Link-Layer-Adresse auflösen, bevor er ein Paket senden kann. RFC 3316 beschrieb GPRS und UMTS anders: Die Verbindung ähnelte einer Punkt-zu-Punkt-Verbindung, der einzige Nachbar des Hosts war der Standardrouter, und die Router-Erkennung hatte ihn bereits identifiziert. Da es auf dieser Schnittstelle keine Link-Layer-Adressen gab, waren Adressauflösung und Next-Hop-Bestimmung dort nicht erforderlich.

Daraus ließe sich leicht die falsche Abkürzung ableiten: Wenn es keine MAC-Adresse zu finden gibt, muss der Host vielleicht auch keinen Nachbarzustand pflegen. Das sagte RFC 3316 nicht. Derselbe Abschnitt verlangte weiterhin Unterstützung für Neighbor Unreachability Detection, kurz NUD, aus der allgemeinen IPv6-Neighbor-Discovery-Architektur. Die Adressauflösung fragt, wie ein Link-Layer-Ziel gebildet wird. NUD fragt, ob ein bekannter Nachbar noch erreichbar ist. Die erste Frage konnte entfallen, ohne dass die zweite verschwand.

Der Grund war betrieblicher Natur. Für Ziele jenseits des direkt angeschlossenen Links braucht ein Host weiterhin einen funktionierenden Next Hop. Eine Punkt-zu-Punkt-Verbindung zeigt, welcher Router am anderen Ende sitzt; sie beweist nicht, dass dieser Router zu jedem späteren Zeitpunkt erreichbar bleibt. Router-Erkennung, Adresskonfiguration, Link-Layer-Auflösung und Nachbarerreichbarkeit hängen zusammen, sind aber keine austauschbaren Nachweise.

Auch die knappe Mobilfunkbandbreite machte wiederholte Steuerungsnachrichten prüfenswert. RFC 3316 schlug vor, Rückmeldungen höherer Protokollschichten zur Erreichbarkeit zu nutzen, wenn der Host bereits IP-Kommunikation in beide Richtungen bestätigen konnte. Eine TCP-Implementierung konnte eine solche Bestätigung nach dem Mechanismus der Neighbor-Discovery-Spezifikation liefern. Bei RTP über UDP konnte ein RTCP-Empfangsbericht, der eingegangene Pakete zeigte, belegen, dass Daten den Kommunikationspartner erreicht hatten – und damit auch den Nachbarn. SIP-Antworten konnten anzeigen, dass Anfragen die Gegenseite erreichten.

In einem engeren Fall auf der Serverseite konnte der Empfang eines SIP-ACK darauf hindeuten, dass eine vorherige Antwort angekommen war. UDP selbst lieferte diese Bestätigung nicht.

Das Argument lautete nicht, dass Anwendungsverkehr NUD überflüssig machte. Eine bereits im Netz vorhandene, aussagekräftige Antwort konnte eine begrenzte Erreichbarkeitsfrage beantworten, ohne eine weitere Sonde hinzuzufügen. Doch jeder Nachweis hatte seinen eigenen Umfang: Ein RTCP-Bericht sagte etwas über den Paketempfang aus, eine SIP-Antwort etwas über einen SIP-Austausch. Keiner bewies den Abschluss eines Anwendungsvorgangs, die Gesundheit aller Pfade oder einen erfolgreichen Dienst für den Nutzer. Ein stiller UDP-Strom wurde nicht dadurch zum Erfolgsnachweis, dass die Verbindung keine MAC-Adresse hatte.

Weitere Anpassungen im RFC unterstreichen diese Trennung. Der Abschnitt zu IPv6 über PPP behandelte eine vom Mobilgerät vorgeschlagene Link-Local-Schnittstellenkennung für angeschlossene Endgeräte. Er verbot diesen Geräten nicht, andere Kennungen für globale oder temporäre Datenschutzadressen zu verwenden. Auch die zustandslose Konfiguration stützte sich auf Präfixe, die innerhalb ihres Geltungsbereichs eindeutig waren, sodass auf der Mobilfunkschnittstelle keine Duplicate Address Detection nötig war. Das waren gezielte Anpassungen auf verschiedenen Schichten, keine pauschale Abschaffung von IPv6-Prüfungen.

2013 löste RFC 7066 RFC 3316 ab und erweiterte den dokumentierten 3GPP-Kontext um das Evolved Packet System neben GPRS und UMTS. Das Nachfolgedokument behielt die Erklärung zu fehlenden Link-Layer-Adressen und die NUD-Anforderung bei. Zusätzlich hielt es fest, dass ein GGSN oder PGW auf eine Adressauflösungsanfrage möglicherweise gar nicht antwortete. Diese Ablösung zeigt, wie sich das 3GPP-Profil mit seinem Geltungsbereich weiterentwickelte; sie verrät nicht, wie viele Geräte ein bestimmtes Verhalten implementierten. Für allgemeine IPv6-Hostanforderungen ist heute RFC 8504 maßgeblich.

RFC 3316 ist daher nicht als vollständige aktuelle Host-Checkliste zu lesen.

Die bleibende technische Lehre ist enger und hilfreicher als „Mobilfunkverbindungen sind besonders“. Ein Link-Typ kann einen allgemeinen Protokollschritt unnötig machen, während die Frage dahinter bestehen bleibt. Hier musste keine Link-Layer-Adresse ermittelt werden; der Host benötigte aber weiterhin einen Nachweis der Erreichbarkeit. Rückmeldungen höherer Schichten konnten redundante Signalisierung einsparen, ohne zum Beweis für den gesamten Dienst zu werden.

Quellen

Die RFCs dokumentieren Protokollhinweise. Sie messen weder Signalisierungseinsparungen noch Funkzuverlässigkeit, Akkulaufzeit, Verbreitung oder Nutzererfahrung.