IPv6 – welche Interface-Adresse wird genutzt?

Kommentieren Drucken
Teil 6 von 6 aus der Serie "IPv6 Blog"

Bei IPv4 war die Adressauswahl noch einfach: es gab eine Ziel-Adresse und eine Absende-Adresse. Nur in Ausnahmen gab es mal mehr. Bei IPv6 sind mehrere Adressen pro Interface nicht nur üblich, sondern Pflicht. Somit muss bei jeder Übertragung das Paar von Adressen gefunden werden, wo Sende- und Empfangsadresse am besten zusammen passen. Im Folgenden wird dieses Verfahren vorgestellt.

Absendeadresse
Wirft man einen Blick auf ein einzelnes Interface seines Rechners, so sieht man eine ganze Reihe von IP Adressen. Neben einer IPv4 Adresse gibt es je nach Betriebssystem und Konfiguration einen ganzen Satz von IPv6 Adressen.

Die beiden Abbildungen 1 und 2 zeigen zwei Beispiele: eines bei OS X und eines von einem iPhone. Beide Beispiele sind aus einem Unternehmensnetz, das mit stateful DHCP betrieben wird.

Wie man erkennen kann, werden verschiedene Adressen erworben, bzw. gebildet:

  • 1x Link Local
    Während OS X die Link Locale IP Adresse mittels EUI-64 aus der Mac-Adresse des WLAN-Interfaces ableitet, nutzt das iPhone dafür den Zufallsalgorithmus der Privacy Extensions.
  • Global
    Auch bei den globalen Adressen unterscheiden sich beide Betriebssysteme:

    • OS X hat drei globale Adressen: eine basiert auf EUI-64, eine ist temporär (privacy extensions) und eine ist per DHCP zugewiesen worden.
    • Das iPhone hat zur Zeit der Aufnahme ebenfalls drei Adressen, davon sind zwei temporär und eine (die letzte) per DHCP erworben.

Bei so viele Adressen stellt sich die Frage: welche nutzen? Diese Entscheidung wird (scheinbar) durch den RFC 6724 geregelt. Warum scheinbar? Nun grundsätzlich gilt bei IP: die Anwendung entscheidet und zwar nicht nur darüber, welche IPv6 Adresse genutzt wird, sondern auch schon, ob überhaupt IPv6 oder nicht doch lieber IPv4. Ein Beispiel für die parallele Nutzung von IPv4 und IPv6 ist Happy Eyeballs, von dem im Netzwerk Insider April 2011 ein Vorentwurf des aktuellen RFC 6555 beschrieben wurde.

Für viele Anwendungen kann jedoch folgende Voraussetzung angenommen werden:

  • Die Anwendung kennt nur einen DNS-Namen.
  • Der Name wird an den resolver des Betriebssystems weitergereicht.
  • Der resolver liefert die IP Adresse bzw. die IP Adressen zurück an die Anwendung.
  • Die Anwendung nimmt die erste IP Adresse in der Liste. Sollte die nicht funktionieren, so versucht sie – mit viel Glück – die nächsten.

Von diesen Annahmen ausgehend, definiert der RFC 6724 sein Regelwerkt, wie die Adressen durch das Betriebssystem / den resolver zu ordnen sind, bevor die Liste an die Anwendung geliefert wird.

Es ist jedoch grundsätzlich festzuhalten, dass die Anwendung entscheidet. Das ist auch vernünftig! Nehmen wir als Beispiel einen Web-Server an, auf dem verschiedene, virtuelle Hosts laufen. In diesem Fall kann es durchaus Sinn machen, diese nicht nur dem Domain Namen zu unterscheiden, sondern ihnen auch unterschiedliche IP Adressen zuzuordnen. Da diese Zuordnung bei öffentlichen Webservern statisch sein sollte, kann man das nicht dem Zufall überlassen, da sie mit dem DNS übereinstimmen muss.

Doch nun zum Regelwerk für Betriebssysteme – also dem Algorithmus der den meisten Kommunikationen zugrunde liegen wird, da nur wenige Programme sich um den Verbindungsaufbau kümmern.

Dazu müssen zuvor noch einige Begriffe definiert und Defaults festgelegt werden.

Scope Vergleich
Scopes gibt es für Multicasts und eingeschränkt für Unicasts. Multicasts können natürlich nur für die Auswahl der Zieladresse in Betracht gezogen werden. Für einen Vergleich des Sende- und Empfangscopes müssen diese einander zugeordnet werden.

Diese Zuordnung zwischen Uni- und Multicast kommt z.B. immer dann zum Tragen, wenn ein System mit seinem Default-Gateway kommuniziert. Sniffert man die Kommunikation mit, so sieht man, dass bspw. während der Autokonfiguration der Client stets die link-locale IPv6 Adresse fe80:… nutzt, auch wenn er schon eine aktive globale Adresse besitzt.

Der Unicast site-local wird vom Standard noch erwähnt, aber nur für Systeme, die diese veralteten Adresse noch nutzen. ULAs werden dem globalen Scope zugeschlagen.

Precedence und Labels
Die „Precedence“ dient dazu, die Zieladressen zu sortieren. Dabei gilt: je höher die Precedence desto eher wird diese Adresse genutzt.
Das Label dient wiederum dem Vergleich von Sender und Empfänger: gibt es ein Adresspaar mit demselben Label, so hat das eine höhere Wahrscheinlichkeit genutzt zu werden.

Auswahl der Kandidaten-Liste der Quelladresse
Zunächst einmal wird eine Liste möglicher Absendeadressen zusammengestellt. Damit sind Multicastadressen und die Loopback Adresse ::1 schon mal per se ausgeschlossen. Hinzu kommen alle Adressen, die Interfachen zugeordnet sind, die nicht funktional sind, heißt nicht aktiv, keinen erreichbaren next-hop haben, obwohl der gebraucht würde. Es kann je nach Zieladresse weitere Gründe geben, die eine Zieladresse per se disqualifizieren.

Es ist zu beachten, dass das nicht für ULAs gilt wenn das Ziel eine globale Adresse ist. Denn grundsätzlich können in einem Unternehmen ja beide Adressen gemischt genutzt werden, so dass ein Endsystem nicht davon ausgehen kann, dass globale Adressen nicht mit einer ULA als Absender funktionieren würden.

Die verbliebenen Adressen gelten als Kandidaten.

Zusammenstellung von Sender- und Empfänger-Pärchen
Allen Kandidaten der Absendeadresse werden nun mit allen möglichen Empfangsadressen kombiniert. In der Regel wird es nur eine Zieladresse geben, so dass die Anzahl der Pärchen identisch ist mit der Anzahl der Kandidatenliste. Erfährt ein Sender bspw. per DNS jedoch mehrere IP Adressen, so vergrößert sich die Anzahl.

Formal gelten bei der Auswahl von Quell- und Zieladresse zwei unterschiedliche Regelwerke. Viele Regeln kommen in beiden Regelwerken vor und die, die doppelt vorkommen, erscheinen in derselben Reihenfolge. Das liegt daran, dass im Grunde nicht zwei Auswahlprozesse stattfinden, sondern das beste Pärchen gesucht wird. Es kann jedoch vorkommen, dass am Ende zwei Pärchen überbleiben, die sich nur in der Quell- oder Zieladresse unterscheiden. Beispielsweise wenn ein Sender eine EUI64 und eine temporäre Adresse mit demselben Präfix hat.

Die formale Definition sieht wie folgt aus, eine verständliche Zusammenfassung für die Praxis steht dann weiter unten:

Auswahl der Quelladresse

  1. Nutze dieselbe Adresse
    Wenn es ein Adresspärchen gibt, bei dem die Zieladresse mit der Quelladresse identisch ist, soll diese genutzt werden.
  2. Nutze kleineres Scope
    Gibt es Adresspärchen mit unterschiedlichen Scops, so soll das mit dem kleinsten genommen werden – bzw. alle anderen werden nicht weiter ausgewertet.
  3. Vermeide abgekündigte Adressen
    Temporäre Adressen werden nicht aktiv genutzt. Wenn ein Rechner bereits eine neue, temporäre Adresse gebildet hat, so soll diese genutzt werden. Das gilt natürlich stets für die eigene Adresse, also Quell-Adresse, da ein System die „Verfallsdaten“ anderer Systeme nicht kennt.
    Diese Regel ist ein klassischer „Tie-Breaker“ und kann nur so verstanden werden, da das Regelwerk sich ja auf die zu nutzende Zieladresse bezieht. Ein Beispiel ist ein Renumbering eines Netzes: kennt man von einem Zielsystem im selben Subnetz zwei Adressen und eines gehört zu einem „veralteten“ Präfix, nutzt man die neue Adresse.
  4. Nutze „home addresses“
    Diese Regel bezieht sich ausschließlich auf Mobile-IP und kann somit nur in diesem Zusammenhang verstanden werden. Wenn kein Mobile-IP genutzt wird, ist diese Regel bedeutungslos.
  5. Bevorzuge die Adressen des sendenden Interfaces
    Angenommen, ein Rechner hat mehrere LAN Schnittstellen (Smartphone mit WLAN und LTE), so soll eine Adresse genutzt werden, die dem sendenden Interface zugeordnet ist. Im Beispiel wäre das die WLAN Schnittstelle, da diese „kostenfrei“ ist.

    • a. Nutze eine Adresse, deren Prefix vom „next-hop“ zugewiesen wurde
      Gibt es mehrere Gateways, die ein System über eine bestimmte Schnittstelle erreichen kann, so soll die Adresse genutzt werden, deren Prefix vom Next-Hop stammt. Also in aller Regel des „default Gateways“. Diese Regel hat ein kleines Problem: Es gibt keinen Standard, der vorschreibt, dass sich ein System merken muss, von welchem Router es welches Prefix bekommen hat. Der RFC selbst sagt, dass diese Regel eher der Vollständigkeit wegen existiert.
  6. Nutze „Matching Labels“
    Gibt es ein Adresspaar aus Sender- und Empfängeradressen, die dasselbe Label haben (s.o.), so sollen diese genutzt werden.
  7. Nutze temporäre Adresse
    Hat ein System mehrere Adressen gebildet, bspw. eine EUI64 und mindestens eine temporäre, so soll die Temporäre bevorzugt werden.
    Diese Regel hat einen wichtigen Zusatz: sollte es eine temporäre und eine feste Adresse geben, so muss eine Schnittstelle zur Applikation existieren, die es der Anwendung ermöglicht, die feste Adresse zu nutzen.
  8. Längstes gemeinsames Präfix
    Gilt aber nur für die ersten 64bit!

Auswahl Zieladresse

  1. Verwirf unerreichbare Adressen
  2. Nutze „matching scopes“ von Quell- und Zieladresse
    Diese Regel besagt soviel wie: wenn es zwischen Sender und Empfänger ein Adresspärchen gibt, das sich im selben Scope befindet, soll dieses genutzt werden.
  3. Vermeide abgekündigte Adressen
    s.o.
  4. Nutze „home addresses“
    s.o.
  5. Nutze „Matching Labels“
    s.o.
  6. Nutze die IP Adresse mit höherer Precendence
    s.o.
  7. Nutze „Native Transport“
    Klingt kompliziert, ist einfach: die Regel besagt nichts anderes, als dass man jegliche Art von Tunnelprotokoll meiden sollte, wenn es nicht nötig ist, da eine Alternative ohne Tunnel existiert.
  8. Nutze „smaller scope“
    s.o.
  9. Längstes gemeinsames Präfix
    Gilt aber nur für die ersten 64bit!
  10. Nutze die gegebene Ordnung
    Hat keine Regel bislang zugetroffen, so wird die Reihenfolge genutzt, die der DNS-Server vorgegeben hat.

Kurzfassung des Regelwerkes
Was wie ein komplexes Regelwerk aussieht, dient dazu möglichst alle Eventualitäten abzudecken. Unter der Voraussetzung, dass keine veralteten Techniken oder Mobil-IP zum Einsatz kommen, kann man das Ganze etwas ungenau wie folgt zusammenfassen:

  1. Nutze keine unerreichbaren Adressen
  2. Nutze das kleinste, gemeinsame Scope
  3. Vergiss alte Adressen
  4. Nimm, was zum sendenden Interface passt
  5. Nutze gleiche gemeinsame Labels
  6. Nutze höhere Precedence
  7. Vermeide Tunnel
  8. Nimm das „longest match“
  9. Nimm die temporäre Adresse

Relevanz für die Praxis
Dieses Regelwerk hat in der Praxis meist folgende Konsequenzen:

  1. Wenn ein System Link-local erreichbar ist und dessen Adresse auch bekannt ist, wird die Link-Locale Adresse genutzt.
    In aller Regel bedeutet das, dass nur der eigene Router per link-locale Adresse kontaktiert wird. Da in DNS keine Link-locale Adressen gepflegt werden sollten.
  2. Sonst wird die Adresse genommen, auf die das Longest Match Kriterium zutrifft, wenn es überhaupt mehr als ein Ziel gibt.
  3. Temporäre lokale Adressen werden gegenüber EUI64 bevorzugt.

So verkürzt ist die Regelung eigentlich verständlich. Jedoch gibt es einen Haken: auch wenn das in aller Regel die drei Kriterien sind, die zum Tragen kommen, muss der Stack jedes Mal die gesamte Liste abarbeiten, da das Longest Match Kriterium erst ganz zum Schluss zum Tragen kommt.

Verglichen mit IPv4 ist die Adressauswahl bei IPv6 somit mit erheblichem Mehraufwand verbunden. Das erschwert nicht nur das Troubleshooting, sondern auch die Entwicklung entsprechender Stacks.

« Teil 5: Troubleshooting IPv6


zugeordnete Kategorien: IP und IPv6
zugeordnete Tags: , , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.