AW: IPv6
Dem Screenshot nach sogar mehrere (Was bei IPv6 durchaus normal ist).
Um Dir genaueres sagen zu können, müßte ich aber mehr von den IPs sehen.
Bisher sehe ich nur, daß es IPv6-Adressen aus dem Pool der Deutschen Telekom sind:
2003:59:: gehört zum Bereich der 649037107316853453566312041152512 (Das ist irgendwas mit "Quintillionen") IPv6-Adressen der Telekom, die zwischen 2003:: und 2003:1fff:ffff:ffff:ffff:ffff:ffff:ffff liegen.
Interessanter ist aber der Rest:
Der Benutzer erhält bei IPv6
ein Subnet von mindestens 18 Trillionen Adressen (Ein sog. /64), in der Praxis aber meist mehr.
Egal ob es 18 Trillionen oder noch mehr sind, braucht der Router nur diese 18 Trillionen und nimmt sich daher aus dem ggf. größeren Pool auch nur dieses benötigte /64er Subnet (Die Fritz!Boxen nutzen auch noch das 2., 3. und 4. mögliche /64er, z.B. für das WLAN-Gastnetzwerk, welches einen separaten Adressraum kriegt, da es ja auch ein separates Netz ist). Die weiteren möglichen Subnetze stellt der Router (Wenn er gut ist) per Prefix Delegation nachgeschalteten Routern zur Verfügung.
Üblich sind /56er, /57er oder /58er Präfixes seitens des Providers, damit stehen dem Kunden 256, 128 oder 64 solcher /64er Subnetze zur Verfügung.
Für Deinen Fall könnte die Sache z.B. so ausgesehen haben:
- Die Telekom hat Dir ein /56er Präfix delegiert, z.B. 2003:0059:0ab0:0000::/56, das wäre der Adressraum 2003:0059:0ab0:0000:0000:0000:0000:0000-
2003:0059:0ab0:00ff:ffff:ffff:ffff:ffff oder die 256 Subnetze von 2003:0059:0ab0:0000::/64 bis 2003:0059:0ab0:00ff::/64
- Dein Router hat sich daraus das erste /64er Subnetz genommen, das wäre dann 2003:0059:0ab0:0000::/64 oder der Adressraum 2003:0059:0ab0:0000:0000:0000:0000:0000-2003:0059:0ab0:0000:ffff:ffff:ffff:ffff
Die ersten 64 Bit bzw. 4 "Tupel" Deiner IPv6-Adressen sind also die Netzwerkadresse, im obigen Beispiel also 2003:0059:0ab0:0000::
Behalte die mal im Auge, die sollten sich bei jeder Neueinwahl verändern (Schön ist das nicht, aber leider haben sich in Deutschland mal wieder dynamische Präfixe durchgesetzt), aus der 2003:0059:0ab0:0000 am Anfang könnte also nach einer Neueinwahl z.B. 2003:107f:ff00:ab00 werden.
Dieser Teil ist daher für die Diagnose wumpe, den darfst Du für Diagnosen ruhig verfälschen (Solange Du so viel vom Anfang stehen läßt, daß man noch sieht, daß es sich um eine öffentliche IPv6 handelt).
Danach folgt der spannendere Teil:
- Jedes Gerät bildet sich eine link-local-address
Aus der Hardware-Adresse/MAC wird, indem man die MAC in der Mitte aufteilt und ff-fe ergänzt, die "EUI-64", und durch Kippen des zweiten Bits der ganzen Soße die IPv6-Interface-ID:
HW-Adresse 94-DE-80-12-34-56 wird also zuerst 94-DE-80-FF-FE-12-34-56 (FF-FE ergänzt), dann 96-DE-80-FF-FE-12-34-56
94 Hex = 10010100 Bin (2. Bit ist 0)
96 Hex = 10010110 Bin (2. Bit ist 1)
und schlußendlich 96de:80ff:fe12:3456, vor den Sermon hängt das Gerät dann noch des reservierte /64er Subnet fe80:: und so wird daraus die link local address fe80::96de:80ff:fe12:3456
Diese Adresse des Gerätes ändert sich niemals, also auch nicht bei Neuinstallationen oder Betriebssystemwechseln, da sich auch die HW-Adresse nicht ändert. Weil diese Adresse auch zur Erzeugung der öffentlichen IPv6 weiterverwendet wird, wird somit die Hardware-Adresse des Gerätes im Internet preisgegeben.
Da dies oft nicht gewünscht ist, kommt hier bereits der erste Teil der "Privacy Extensions" ins Spiel. Sind die Privacy Extensions aktiv, dann wird vom Betriebssystem einmalig eine IPv6-Interface-ID "gewürfelt", statt sie auf Grundlage der HW-Adresse zu berechnen. Für die Lebenszeit der Installation bleibt diese dann unverändert.
Der Vorteil, daß die Hardware-Adresse nicht mehr preisgegeben wird, wird damit erkauft, daß sich diese erzeugte Adresse bei Betriebssystemwechseln/Multi-Boot oder Neuinstallationen ändern wird.
Diesen Aspekt müßtest Du bei Deiner ifconfig-Ausgabe auch anhand der dort stehenden HW-Address und der fe80::-Adresse nachvollziehen können:
Entweder ist die link-local-address direkt aus der Hardware Address abgeleitet oder bei der Ersteinrichtung gewürfelt. Auf den meisten "primitiven" Devices wie E2-Boxen etc. pp. wird hier die HW-Adresse verwendet.
- Nun kommt der Router ins Spiel und gibt im LAN bekannt, daß das Subnet 2003:0059:0ab0:0000:: zur Verfügung steht.
Jedes Gerät im Netz würde jetzt normalerweise ganz einfach seine o.g. IPv6 Interface ID mit dem veröffentlichten (advertised) Subnet zu einer neuen, öffentlichen Adresse verbinden, für unser Beispielgerät also 2003:0059:0ab0:0000:96de:80ff:fe12:3456.
Diese IPv6-Adresse wäre somit schon mal die erste öffentliche IPv6 des Gerätes. Bei einem statischen Präfix wäre diese Adresse komplett statisch, bei dynamischem Präfix ändern sich bei jeder Neueinwahl die ersten 4 Tupel (Das Subnet), aber nicht die letzten 4 Tupel (Die Interface ID).
Um einen Server zu erreichen, würde man diese statische oder eben halbstatische IPv6-Adresse nutzen.
- Jetzt kommt der zweite Teil der Privacy Extensions ins Spiel:
Weil manche Paranoiker nicht möchten, daß nachvollziehbar ist, welches Gerät im Heimnetz auf's Internet zugreift (Die Wahrscheinlichkeit, daß zwei Geräte dieselbe Interface ID besitzen geht gegen Null), wird bei aktiven Privacy Extensions eine zusätzliche Interface ID gewürfelt und zwar alle paar Minuten (Einstellbar).
Aus dem advertised prefix und dieser Zufalls-ID wird dann eine zusätzliche öffentliche IPv6-Adresse erzeugt. Der hintere Teil ändert sich ständig (im eingestellten Intervall), der vordere nicht (bei statischem Präfix) oder bei jeder Neueinwahl (bei dynamischem Präfix).
Mit dieser IPv6-Adresse greift das Gerät bevorzugt auf das Internet zu. Diese Tatsache wird wichtig, wenn man einen DynDNS-Client einrichtet ...
- Sich ändernde Teile einer IPv6-Adresse behalten ihre Gültigkeit noch für eine gewisse Zeit nach der Änderung.
Wird also z.B. während einer bestehenden Verbindung ein neues Präfix advertised (Manche Provider wechseln das Präfix auch bei laufender Verbindung), bleibt das alte noch eine Weile gültig, um bestehende Verbindungen nicht abreißen zu lassen. Während dieser Zeit hat jedes Gerät ca. doppelt so viele Adressen (Einmal mit altem und einmal mit neuem Präfix).
Für die "Surf-IP" der Privacy Extensions gilt das analog: Nach Generierung einer neuen zufälligen Interface ID bleibt die alte noch eine Weile gültig, um zuvor angeforderte Antworten noch empfangen zu können.
Im Ergebnis erhalten wir also:
Ohne Privacy Extensions mindestens 2 IPv6-Adressen, eine link local address beginnend mit fe80:: und eine öffentliche, ganz oder teilweise statische, beginnend mit dem öffentlichen Subnet. Beide enden mit der aus der HW-Adresse erzeugten IPV6-Interface ID.
Mit Privacy Extensions mindestens 3 IPv6-Adressen, nämlich die beiden o.g., nur daß die IPv6-Interface-ID nicht aus der HW-Adresse erzeugt wurde, sowie eine weitere mit ständig wechselnder Interface-ID.
Weil die ständig wechselnde IPv6 ihre Gültigkeit nach einem Wechsel noch eine Weile behält, werden es meistens sogar 2 dieser wechselnden und damit insgesamt 4 Adressen sein.
Jetzt kommen wir zum DynDNS:
Eigentlich sollte mit IPv6 die Zeit der DynDNS-Updates vorbei sein. Da der Adressraum groß genug ist, könnte man problemlos jedem Kunden ein festes Präfix zuteilen.
Leider macht man das nicht (NetCologne macht es auf Kundenwunsch), sondern verwendet dynamische Präfixe, deshalb "dürfen" wir uns weiter mit DynDNS-Updates rumschlagen, weil aber nun jedes Gerät eine
eigene Adresse hat, muß
für jedes Gerät, auf dem ein Server von außen erreichbar sein soll, ein separates DynDNS-Update gemacht werden.
Das zweite Problem:
DynDNS-Clients gehen bei einem Update so vor, daß sie zuerst über einen Zugriff auf einen Web-Server die aktuelle IP ermitteln und diese dann beim DynDNS-Anbieter "hochladen" oder einfach direkt auf den DynDNS-Anbieter zugreifen und dieser dann mit der IP aktualisiert, von der aus der Zugriff erfolgt.
Bei aktiven Privacy Extensions verwenden sie dazu aber - wie der Rest des Systems auch - die ständig wechselnde "Privatsphären-IP", so daß unentwegt Updates nötig wären, um den Server erreichbar zu halten.
Um das zu vermeiden, sollte man sicherstellen, daß die
Updates mit der sich nicht ändernden IP-Adresse erfolgen.
Dazu muß man an sich lediglich rausfinden, welche das ist, im Regelfall ist es die, die genauso endet wie die link-local-address.
Angenommen, ifconfig zeigt uns momentan folgendes an:
inet6 address 2003:0059:0ab0:0000:
7645:ab65:7352:ff87/64 Scope:Global
inet6 address 2003:0059:0ab0:0000:45fc:b65:1278:abc5/64 Scope:Global
inet6 address 2003:0059:0ab0:0000:379b:e562:1452:556/64 Scope:Global
inet6 address fe80::
7645:ab65:7352:ff87/64 Scope:Link
dann wäre 2003:0059:0ab0:0000:7645:ab65:7352:ff87 die für einen Server und damit auch für DynDNS-Updates zu nutzende (halb-)statische IPv6.
Wenn die DynDNS-Updates durch wget erfolgen, dann würde man nun den Parameter
--bind-address [2003:0059:0ab0:0000:7645:ab65:7352:ff87]
anhängen, damit wget die Verbindung von dieser Adresse und nicht von der wechselnden aus aufbaut.
Und da beißt sich die Katze in den Schwanz:
Da ja auch das Präfix dynamisch ist (Sonst bräuchten wir auch keine Dyn-Updates), muß der Wert für diesen Parameter nach jedem Präfix-Wechsel neu bestimmt werden.
Nach einem Präfix-Wechsel hätte das selbe Gerät z.B. folgende IPv6-Adressen:
inet6 address 2003:01ab:1f90:0000:
7645:ab65:7352:ff87/64 Scope:Global
inet6 address 2003:01ab:1f90:0000:54c1:1c57:f2b8:d715/64 Scope:Global
inet6 address 2003:01ab:1f90:0000:759b:e6b2:42b2:556/64 Scope:Global
inet6 address fe80::
7645:ab65:7352:ff87/64 Scope:Link
Unsere beiden "Privatsphären-IPs" haben sich komplett umgewürfelt, da sich Präfix und auch die Zufalls-ID geändert haben, bei der "festen" IP ist zwar das Suffix gleich geblieben, aber das Subnet/Präfix ist nun ein anderes.
Der wget-Parameter wäre nun also
--bind-address [2003:01ab:1f90:0000:7645:ab65:7352:ff87]
...
Da kommt also zusätzlicher Scripting-Aufwand dazu, um zuerst das aktuelle Präfix zu ermitteln und dieses dann mit der richtigen "Server-IP" zu verbinden, damit das Update mit dieser durchgeführt wird.
Gut haben es diejenigen mit Fritz!Box, da kann die Fritz!Box die Updates über den MyFritz!-Dienst mit erledigen.
Allen anderen würde ich empfehlen, den Teil der Privacy Extensions mit den ständig wechselnden IPs abzuschalten, damit wäre das Problem ebenfalls erledigt. Wenn der Server eh nur eine öffentliche IPv6-Adresse hat, nutzt er die ganz automatisch bei seinen Dyn-Updates und da er als Server ja nunmal erreichbar sein soll, wofür es am besten wäre, die IP würde sich gar nicht ändern, hätten die Lämmerschwanz-IPs auch gar keinen Sinn.
