Was IPv6CP aushandelt und was weiterhin ein Präfix braucht
Eine Link-Local-Adresse auf dem PPP-Interface ist ein Einrichtungsschritt, kein IPv6-Zugang. Trennen Sie den Identifikator-Austausch von Präfixen, Routen und Client-Integration.
IPv6 kommt auf dem PPP-Interface hoch, eine Link-Local-Adresse erscheint, und die Änderung wird für erledigt erklärt. Dann wird nichts geroutet, es gibt keine globale Adresse, und ein Test zu einem öffentlichen Ziel schlägt fehl, während das Interface weiterhin konfiguriert aussieht. Die Verbindung kam hoch; das Netzwerk nie. Arbeiten Sie die vier Prüfungen unten der Reihe nach ab und bleiben Sie bei der stehen, die die Lücke erklärt.
Was eine Link-Local-Adresse tatsächlich beweist
IPv6CP bringt IPv6 auf der PPP-Verbindung hoch und handelt je Seite einen Interface-Identifikator aus. Dieser Identifikator erzeugt eine Link-Local-Adresse, die ausreicht, um mit dem Peer über die Verbindung zu sprechen, und nicht ausreicht, um irgendetwas anderes zu erreichen. Die Adresse beweist, dass die Verbindung für IPv6 bereit ist, und sie beweist nichts über das Netzwerk hinter dem Peer. Sie als Zugangsadresse zu lesen, ist der Fehler, mit dem die meisten dieser Untersuchungen beginnen.
Die vier Fragen unten trennen, was die Link-Schicht klärt, von dem, was der Dienst liefern muss. Beantworten Sie sie der Reihe nach, denn eine spätere Frage lässt sich nicht beantworten, solange eine frühere offen ist.
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
Woher das Präfix kommen muss
Eine globale Adresse braucht ein Präfix von irgendwoher: eine Router-Ankündigung, ein delegiertes Präfix, DHCPv6 oder statische Konfiguration. IPv6CP trägt keines, und kein Warten auf der Verbindung erzeugt eines. RFC 5072 ordnet IPv6CP als den Einrichtungsschritt ein, der läuft, bevor andere IPv6-Protokolle auf der Verbindung arbeiten, und das ist der ganze Umfang: die Verbindung vorbereiten, nicht das Netzwerk nummerieren. Liefern Sie das Präfix, und das Interface beginnt, Verkehr zu tragen, statt nur zu existieren.
Router-Ankündigungen sind die übliche Antwort im LAN und eine weniger zuverlässige in einem Punkt-zu-Punkt-Tunnel, weil der Client sowohl Aufforderungen senden als auch die Antwort annehmen muss. Manche Tunnel-Clients tun weder das eine noch das andere. Prüfen Sie, was der Client anzunehmen bereit ist, bevor Sie entscheiden, dass der Server es senden soll.
Dasselbe Präfix muss vom anderen Ende erreichbar sein. Ein Client, der eine globale Adresse, aber keinen Rückweg hat, ist konfiguriert, nicht verbunden.
Routen sind ein separates Versprechen
Auch mit einer Adresse muss der Client wissen, welche Ziele in den Tunnel gehören, und der Server braucht einen Rückweg für diese Ziele. Das sind zwei Entscheidungen an zwei Stellen. Ein Tunnel, der den gesamten IPv6-Verkehr trägt, braucht eine Standardroute auf dem Client und eine Rückroute auf dem Server; ein Split-Tunnel braucht auf beiden Seiten dieselbe Präfixliste. Wenn sie nicht übereinstimmen, verlässt der Verkehr das Netz und kehrt nie zurück.
Schreiben Sie die Liste auf, bevor Sie irgendetwas konfigurieren. Wenn der Plan sagt, dass nur das Unternehmenspräfix durch den Tunnel geht, sollte der Client keine Standard-IPv6-Route haben, und der Server sollte keine ankündigen.
Die Client-Integration entscheidet den Rest
Manche Tunnel-Clients konfigurieren IPv6 explizit. Apples Network Extension etwa nimmt eine Adresse, ein Präfix und eine Reihe von Routen für den Tunnel, sodass eine Anwendung, die sie nutzt, nicht auf eine Ankündigung im Ethernet-Stil wartet. Andere verlassen sich auf Router-Ankündigungen, die über die Verbindung eintreffen. Beide Modelle sind legitim und verlangen unterschiedliches Serververhalten, sodass die falsche Wahl einen Client erzeugt, der ewig auf eine Nachricht wartet, die niemand sendet. Bestimmen Sie das Modell, bevor Sie den Server ändern.
Ein alter Interface-Name wie ppp0 beweist nichts über den Stack, der heute läuft. Ein aktueller Client kann eine Paket-Tunnel-API statt eines PPP-Interface verwenden, und anzunehmen, er verhalte sich wie eine historische Verbindung, ist der Weg, ein funktionierendes Design zu zerstören. Fragen Sie nach Client-Version und Bereitstellungsmethode, nicht nach dem Interface-Namen.
Schreiben Sie den Plan, den der Client braucht
Eine vollständige Beschreibung deckt drei Dinge ab: welche Adresse der Client hält, welche Ziele der Tunnel tragen soll und wie das Netzwerk Antworten zurücksendet. Eine Link-Local-Adresse beantwortet keines davon, und eine angenommene Ankündigung beantwortet nur einen Teil eines davon. Prüfen Sie jeden Punkt einzeln, statt eine grüne Anzeige zu akzeptieren. Halten Sie dann fest, welcher Mechanismus welche Antwort geliefert hat, denn dieser Eintrag macht den nächsten IPv6-Bericht zu einer Zwei-Minuten-Prüfung.
Bewahren Sie den Eintrag mit der Dienstdokumentation auf und aktualisieren Sie ihn, wenn sich der Client ändert. Ein Plan, der für einen PPP-Client richtig war, kann für einen Paket-Tunnel-Client beim selben Dienst falsch sein. Die vier Fragen bleiben gleich; nur die Antworten verschieben sich.