Zusammenfassung

  • Der v6ops-Arbeitsgruppenentwurf vom 28. Oktober, Fassung 02, verlangt für einen ICMPv6-Fehler mit nicht abbildbarer äußerer IPv6-Quelle eine verfügbare öffentliche IPv4-Adresse als bevorzugte Quelle der ICMPv4-Antwort. Fehlt sie, muss der Übersetzer 192.0.0.8 verwenden. Fassung 01 enthielt diese Prioritätsentscheidung noch nicht ausdrücklich.
  • Die ursprüngliche IPv6-Adresse soll in einem Node-Identification-Objekt mitreisen. Bei Packet Too Big kann das Objekt erst nach der Übersetzung angehängt oder weggelassen werden; die Fehlermeldung soll dennoch ankommen. IANA führt 192.0.0.8/32 als IPv4-Dummy-Adresse.

Eine Quellenadresse kann bloß der Umschlag sein

Die Fehler Destination Unreachable, Time Exceeded und Packet Too Big sagen dem Absender etwas Wichtiges über einen Verbindungsweg. Wurde IPv4-Verkehr durch eine IPv6-only-Strecke geführt, kann der Fehler von einer IPv6-Adresse kommen, die weder zum Übersetzungspräfix passt noch einen statischen oder zustandsbehafteten IPv4-Eintrag hat. Der Übersetzer kann diese 128 Bit nicht in das 32-Bit-Quellfeld der ICMPv4-Antwort schreiben. Hat er selbst keine öffentliche IPv4-Adresse, steht auch kein eigener öffentlicher Absender für die Antwort bereit.

Abschnitt 4.1 der neuen Spezifikation im Entwurf setzt deshalb zwei Bedingungen. Eine vorhandene öffentliche IPv4-Adresse oder ein entsprechender Pool sollte zuerst eingesetzt werden, wie es der ältere Weg aus RFC 6791 ermöglicht. In allen anderen Fällen ist 192.0.0.8 Pflicht. Die Vorfassung empfahl die Dummy-Adresse allgemein bei nicht abbildbarer Quelle. Die neue Reihenfolge nimmt die Ressourcenlage des konkreten Übersetzers ernst: Wer eine öffentliche Adresse hat, nutzt sie; wer keine hat, verliert nicht allein deshalb den diagnostischen Rückkanal.

Die IANA-Sonderadressliste bezeichnet den /32 als „IPv4 dummy address“ nach RFC 7600. Er darf nach der Tabelle als Quelle dienen, ist aber kein gültiges, weiterleitbares oder global erreichbares Ziel. Die Anzeige 192.0.0.8 in einer Diagnose ist somit ein Hinweis auf den Übersetzungsersatz und keine Entdeckung eines Routers mit dieser echten Identität. Wer den Wert als Hop auf einer Netzkarte einträgt, verwechselt den Umschlag mit seinem Verfasser.

Für die Herkunft gibt es einen zweiten Kanal. Der Übersetzer sollte ein Node-Identification-Objekt anfügen, dessen IP-Adress-Unterobjekt die ursprüngliche IPv6-Quelle trägt. Wenn er das Objekt anfügt, muss die Adresse enthalten sein und die Prüfsumme des Erweiterungskopfs angepasst werden. Ist die IPv6-Quelle regulär übersetzbar, darf der Übersetzer weder die Dummy-Adresse noch dieses zusätzliche Objekt einsetzen. Der Ausnahmeweg ist an ein fehlendes Mapping gebunden, nicht an die Vorliebe einer Diagnoseoberfläche.

Der Empfänger muss die Erweiterung schließlich lesen. Der Entwurf nennt traceroute-artige Werkzeuge, die Node Identification interpretieren und anzeigen können. Ein Paket kann die ursprüngliche IPv6-Adresse enthalten, während der Bildschirm nur den Dummy-Wert zeigt. Auch deshalb ist eine korrekte Paketstruktur noch keine brauchbare Beobachtung für den Menschen am Leitstand.

Bei Packet Too Big wird die Reihenfolge sichtbar

Packet Too Big meldet, dass eine Paketgröße auf dem Weg nicht passt. Die nötige ICMP-Erweiterung lässt sich einem ICMPv6-PTB nicht vor der Übersetzung in der vorgesehenen Form hinzufügen. Erst die ICMPv4-Antwort kann das Node-Identification-Objekt erhalten. Der Entwurf erlaubt, dieses Objekt in dem Sonderfall wegzulassen, empfiehlt aber weiterhin, den Fehler mit Dummy-Quelle zu übersetzen und ihn nicht zu verwerfen.

Das ist ein absichtlicher Vorrang für den Nutzwert der Größenmeldung. Die Herkunft kann in diesem Zweig unvollständig bleiben; der Absender soll dennoch erfahren, dass sein Paket zu groß war. Würde man die Rückgabe der Meldung davon abhängig machen, dass auch die Herkunft stets perfekt dargestellt ist, könnte eine optionale Identitätserweiterung den grundlegenden Fehlerkanal blockieren.

Der Übersetzer muss außerdem entscheiden, ob ein ICMPv6-Fehler überhaupt aus zuvor übersetztem IPv4-Verkehr stammt. Ein eigener IPv6-Bereich oder ein eigenes /64 macht das leicht. Nutzt eine Adresse sowohl übersetzte als auch native IPv6-Verbindungen, kann zusätzlicher Zustand oder die Auswertung des auslösenden Pakets erforderlich sein. Die IANA-Reservierung trifft diese Zuordnung nicht für das Gerät.

Der Datatracker führt Fassung 02 als Arbeitsgruppen-Internet-Draft, dem IESG vorgelegt und noch in AD-Evaluation. Nach einer Genehmigung soll sie RFC 6791 und RFC 7915 aktualisieren. Sie verlangt keine neue IANA-Zuteilung und enthält keine Messung eines laufenden Übersetzers. Frühere Artikel über Node Identification betrafen generelle Offenlegung und unbekannte AFI-Werte. Hier geht es um die Wahl der Absenderadresse und um das Überleben eines Fehlers an der IPv6/IPv4-Grenze.

Quellen