Unitymedia willkürlicher Verbindungsaufbau über IPv4 oder IPv6

[GoaSkin]

Hallo,

ich richte gerade einen Horde-Groupware-Server bei einem Dualstack-fähigen Hoster ein und versuche, von einem Unitymedia DS-Lite-Anschluss drauf zuzugreifen.

Ich stelle fest, dass ich mich ständig neu anmelden muss mit der Begründung "Ihre IP-Adresse hat sich geändert. Sie wurden zur Sicherheit abgemeldet". Und das Apache-Webserver-Log zeigt, dass für einzelne HTTP-Requests der Absender nicht meine IPv6-Adresse ist, sondern da vereinzelt auch das AFTR-Gateway von Unitymedia auftaucht.

Ist das normal, dass IPv6 im Einzelfall versagt und dann auf IPv4 zurückgegriffen wird. Oder ist der Fehler höchstwahrscheinlich auf dem Client-Rechner zu suchen?

 

[tq1199]

Ist das normal, dass IPv6 im Einzelfall versagt und dann auf IPv4 zurückgegriffen wird. Oder ist der Fehler höchstwahrscheinlich auf dem Client-Rechner zu suchen?

Ich denke der Fehler ist beim Router/Gateway des DS-Lite-Anschlusses (Client) zu suchen. Der Client am DS-LIte-Anschluss wird in diesem Fall (... mit dem AFTR-Gateway), nach außen zwei externe IPv6-Adressen haben, die beim (IPv6)-Server abwechselnd "ankommen" und den (IPv6-)Server "verwirren".

 

[OlliL]

Ist denn sichergestellt das der Browseraufruf auch immer den AAAA Eintrag verwendet oder nicht auch manchmal auf IPv4 (A) zurückfällt? Wenn da ein AFTR auftaucht, kann das eigentlich nur passieren, wenn der Client IPv4 Anfragen abschickt.

 

[GoaSkin]

Ist denn sichergestellt das der Browseraufruf auch immer den AAAA Eintrag verwendet oder nicht auch manchmal auf IPv4 (A) zurückfällt? Wenn da ein AFTR auftaucht, kann das eigentlich nur passieren, wenn der Client IPv4 Anfragen abschickt.

Hallo,

als Browser wird ein normaler Firefox ohne irgendwelche Add-Ons genutzt. Für den Webserver gibt es einen A- und einen AAAA-Eintrag. Er ist unter seinem Domänen-Namen per IPv4 und IPv6 erreichbar.

 

[tq1199]

Er ist unter seinem Domänen-Namen per IPv4 und IPv6 erreichbar.

Welcher Absender wird beim Webserver angezeigt, wenn Du diesen von einem DS-Lite-Anschluss, per IPv4 erreichst?

 

[tq1199]

Ist denn sichergestellt das der Browseraufruf auch immer den AAAA Eintrag verwendet oder nicht auch manchmal auf IPv4 (A) zurückfällt?

Gibt es für diese Sicherstellung eine "besondere" Konfiguration für den Browser (oder evtl. auch für das Betriebssystem), wenn dieser an einem DS- oder DS-Lite-Anschluss benutzt wird?

 

[GoaSkin]

Welcher Absender wird beim Webserver angezeigt, wenn Du diesen von einem DS-Lite-Anschluss, per IPv4 erreichst?

In über 90% der Fälle korrekt meine IPv6-Absender-IP. Irgendwann ist der Absender dann für einen einzelnen HTTP-Request aftr-37-201-170-39.unity-media.net, woraufhin sofort die Session ungültig ist.

 

[tq1199]

Welcher Absender wird beim Webserver angezeigt, wenn Du diesen von einem DS-Lite-Anschluss, per IPv4 erreichst?

In über 90% der Fälle korrekt meine IPv6-Absender-IP. ...

Ich meinte aber, beim Zugriff per IPv4. D. h., es wird fast immer die externe IPv6-Adresse angezeigt, auch wenn der Zugriff per IPv4 erfolgt?

 

[GoaSkin]

Wenn ich IPv6 deaktiviere, erfolgt natürlich ein reiner IPv4-Zugriff über das AFTR-Gateway. Sofern sowohl der Client und der Server Beides machen, geschehen fast alle HTTP-Requests über IPv6, aber irgendwann kommt ein Einzelner über IPv4 mit dem Ergebnis, dass mich die Web-Applikation rauswirft (IP nicht mehr gültig). Da werden mit jedem Klick Zig Dateien vom Webserver abgerufen. Irgendwann wird (versehentlich) mal IPv4 genutzt und ich habe den Salat. Im Apache-Access-Log geschieht da ein Einzelrequest über IPv4, umgeben von massenweise IPv6-Requests. Die vereinzelten IPv4-Requests erscheinen dabei willkürlich. Es betrifft nicht immer die selben HTTP-Requests, die über IPv4 statt IPv6 abgefragt werden. Auch kommt es vor, dass eine PHP-Datei, mehrere Bilder und Javascript-Includes abgerufen werden und dabei ein einzelnes Bild über IPv4.

 

[tq1199]

..., aber irgendwann kommt ein Einzelner über IPv4 mit dem Ergebnis, dass mich die Web-Applikation rauswirft (IP nicht mehr gültig). ...

D. h., obwohl Zugriff per IPv4, wird als Absender-Adresse eine IPv6-Adresse beim Server angezeigt? Oder wird eine IPv4-Adresse beim Server angezeigt und es heißt dann trotzdem "IP nicht mehr gültig"? Wenn das der Fall ist, dann könnte das auch mit DS von Client-Seite aus, so sein und das wäre für mich ein Hinweis, dass DS-Lite und DS noch keine ausgereifte Technik (... für diese Nutzungsart) ist. Da kann ich verstehen, das manche mit DS, z. Zt. die IPv6-Unterstützung deaktivieren.

 

[GoaSkin]

..., aber irgendwann kommt ein Einzelner über IPv4 mit dem Ergebnis, dass mich die Web-Applikation rauswirft (IP nicht mehr gültig). ...

D. h., obwohl Zugriff per IPv4, wird als Absender-Adresse eine IPv6-Adresse beim Server angezeigt? Oder wird eine IPv4-Adresse beim Server angezeigt und es heißt dann trotzdem "IP nicht mehr gültig"? Wenn das der Fall ist, dann könnte das auch mit DS von Client-Seite aus, so sein und das wäre für mich ein Hinweis, dass DS-Lite und DS noch keine ausgereifte Technik (... für diese Nutzungsart) ist. Da kann ich verstehen, das manche mit DS, z. Zt. die IPv6-Unterstützung deaktivieren.

Nein... auf dem Server wird eine IPv6-Adresse angezeigt, wenn der Zugriff über IPv6 geschieht und eine IPv4-Adresse, wenn er über IPv4 geschieht. Da aber sowohl Client als auch Server IPv6 können, sollte es garkeine IPv4-Verbindungen geben. Trotzdem kommen vom Client vereinzelt HTTP-Requests (jeder Datei-Abruf = eine neue Verbindung, wie das bei HTTP halt so ist) Anfragen per IPv4 an, in dem Fall mit dem AFTR-Gateway als Absender.

 

[tq1199]

... Anfragen per IPv4 an, in dem Fall mit dem AFTR-Gateway als Absender.

Ist hier (in diesem Fall) die IP-Adresse des AFTR-Gateways (als Absender), eine IPv4-Adresse oder eine IPv6-Adresse?

 

[GoaSkin]

Eine IPv4-Adresse.

 

[SpaceRat]

Nach Norm ist bei vorliegen einer Dual-Stack-Verbindung für den Zugriff auf einen IPv6-fähigen Server auch IPv6 zu verwenden.
Ausgenommen sind Teredo- und sonstige 6to4-Tunnel, bei denen ist IPv4 zu bevorzugen.

Theoretisch sollten also alle Zugriffe auf diesen Web-Server vom DS-lite-Anschluß aus per IPv6 erfolgen.

Nun kommt das "Aber":
Gerade Browser legen diese Norm sehr großzügig aus und fallen sehr schnell, oftmals zu schnell, wieder auf IPv4 zurück.

Das Problem:
Niemand mißt einen Browser daran, ob er korrekt arbeitet, sondern daran ob er Seiten schnell aufbaut, auch solche die fehlerhaft sind oder die auf besch1ssen konfigurierten Servern laufen.

Leider gibt es auf der Welt auch jede Menge unfähiger Admins (Ich warte z.B. seit über einem Monat darauf, daß das Rechenzentrum meines Hosters mir zumindest eine einzige /128 korrekt auf den Server geroutet kriegt ... solange muß ich die fehlerhaft geroutete /128 noch bei jedem Systemstart wieder vom Interface löschen ...) und die Browser scheinen derzeit noch beim kleinsten Schluckauf davon auszugehen, daß serverseitig ein Fehler vorliegt, damit sie die Seite trotzdem schnell aufgebaut kriegen, dann halt über IPv4.

Dann gibt es natürlich auch noch die ganzen Hobby-Admins zuhause, die es regelmäßig nicht hinkriegen, ihr Netzwerk sauber zu konfigurieren. Es gibt genug Netzwerke, in denen den Clients gesagt wird, es gäbe IPv6, aber in Wirklichkeit gibt es keine entsprechende Außenanbindung.
Würden sich die Browser korrekt/anders verhalten, würde in diesen Netzwerken kein Zugriff mehr gehen ...


Wirklich vermeiden kann man das derzeit eigentlich nur, indem man auch einen IPv6-only-Host für seinen Server anlegt, so wie es Google mit "ipv6.google.com" und Heise mit "six.heise.de" getan hat.

 

[GoaSkin]

So... das Firefox Add-On "6or4" kommt der Sache ein Stück näher.

Sofern eine prinzipiell über IPv6 erreichbare Webseite per IPv4 abgerufen wird, ist der Browser zu diesem Zeitpunkt der Meinung, die Webseite kann nicht über IPv6 abgerufen werden. Das Plugin listet dann für die Zielseite nur eine IPv4-Adresse. Aktualisiert man und es wird danach über IPv6 verbunden, hat die Zielseite gemäß dem Add-On wieder Beides. Also entweder will der Browser IPv6 manchmal nicht nutzen oder der Unitymedia-Nameserver gibt nicht immer einen AAAA-Record aus.