Wollen wir mal hoffen.
Aber der Betreiber von…
http://www.havevirginmediaenabledipv6yet.co.uk/
…hat’s eingerichtet 15 Jahre her & da ist immer noch kein IPv6 in sicht. 
Das geht jetzt aber soweieso alle am eigentliche Topic vorbei. @monbijou hat ein Problem mit SEINER Fritte. Du hast das nicht, ich habe es auch nicht an der Fritte und auch nicht an meiner pfsense. Sehr viele andere haben mit den Fritten auch keine Probleme. Nur einige wenige wie @monbijou.
Es ist also sehr wahrscheinlich, dass es irgendwas mit der Konfiguration der Fritten und z.B. CDN zu tun hat und kein generelles Problem bei ipv64 ist. Genaues weiß man nicht.
Daher sollte man erst einmal die Basiskonfiguration hinbekommen. Also DynDNS fehlerfrei konfigurieren und testen und dann weitere Elemente wie CDN hinzufügen.
Wie ich zuvor schon schrieb immer ein Schritt nach dem anderen und nicht alles auf einmal.
1 „Gefällt mir“
@The_eagle
Natürlich läuft das CDN. Für was anders um nach Hause zu telefonieren nutze ich IPV64 nicht.
Und das mit dem Ping hast Du endlich mal gesagt dass das bei CDN nicht funktioniert. Danke dafür.
Und sobald ich das CDN ausschalten funktioniert die Fritzbox ohne die Fehlermeldungen. DYNDNS und PING gehen dann.
Somit ist alles korrekt eingestellt.
Sobald ich CDN anschalte geht es wieder los dass die Fritzbox Schwierigkeiten hat.
[DynDNS-Fehler: Der angegebene Domainname kann trotz erfolgreicher Aktualisierung nicht aufgelöst werden.]
Macht mir aber nix da ich trotzdem nach Hause telefonieren kann. Und meine öffentliche IPV6 wird immer nachts um 4:30 erneuert.
Ich frag jetzt mal AVM wie die das mit der Auflösung machen. Evt. benutzen die ein PING um das zu prüfen. Und das geht bei CDN nicht. Haben wir jetzt gelernt. Sobald ich was weiß berichte ich.
@DaveTheDane
Und wie kommst Du weiter. Dein Thema ist noch immer nicht gelöst. Hast Du noch die Timeouts? Was für Ansätze wirst Du verfolgen? Gibts was Neues?
Ich antworte später. Jetzt gibt’s Formel 1 in RTL…
Und wieso habe ICH das endlich mal gesagt??? Denkst du ich bin hier der Admin? Nope, bin ich nicht. Nutze ipv64 lediglich. Ganz genau so wie du auch.
Und wenn du nicht sagst dass du CDN anpingen willst statt der Ipv6-Adresse der Fritte, dann kann das auch keiner außer dir wissen.
Und das CDN nicht anpingbar ist, ergibt sich aus der Logik des CDN selbst. Reverse Proxy betrifft nur TCP 80/443. Bei Portmapper werden beliebige Ports (nur UDP/TCP stehen dafür zur Auswahl) gemappt. ping ist aber aber ICMP und das ist sozusagen Grundschulwissen Netzwerk. Sollte wirklich jeder, der sich damit befasst auch wissen.
Gut zu wissen. Danke.
Gestern gab’s 10 Updates, davon 3 ausgetimed nach die von mir vorgegebene 3 Sek.
Im Schnitt dauerte die erfolgreiche Updates 1,4 Sekunden.
Zum Vergleich, liegt ddnss.de bei 0,4 Sekunden, aber ipv64.net hat die bessere Funktionalität, finde ich.
Es gibt ein Paar Dinge die ich optimieren kann:
die Java HttpClientBuilder & HttpRequestBuilder können wiederverwendet werden.
Das könnte evt. 200 ms sparen.
Dazu wird die EierlegendeWollMilchSau Fassung der Proxy gerade neu geschrieben.
Die ist Multi-Provider- & Multitasking-fähig & deutlich komplexere als die Light Fassung.
Das dauert ein bißchen…
Von den 7 erfolgreiche Updates waren 2 der Aufträge vom Fritz!Box fehlerhaft.
Ich habe 3 Fehler in der Fritz!Box DynDNS Funktion entdeckt:
a) manchmal ist die &ip6 Key vorhanden in der URL, aber ohne Wert
b) das Gleiche gilt für &ip4 aber sehr selten
c) manchmal wird für &ip6lanprefix der Wert vom vorrige DSL-Einwahl übergeben
@monbijou
Ich versuche gerade mit IPv6 Addresse statt Rechnername in der Fritz!Box Update URL.
Klappt nicht. Kein Fehlermeldung. Gar nichts.
Kommt bei mein Proxy nicht an, obwohl die genau auf die Addresse hörcht.
Könntest du die ipv64.net in dein Update URL mit [2a01:4f8:192:1326::bad:c0de] ersetzen?
Danach ein „Neu Verbinden“ in der Box auslösen & schauen op ein Update geschieht?
Die Update URL wurde dann ungefähr so aussehen:
https://[2a01:4f8:192:1326::bad:c0de]/nic/update?key=1234567890abcdefgh&domain=<domain>&ip=<ipaddr>&ip6=<ip6addr>&ip6lanprefix=<ip6lanprefix>
Hallo Dennis,
jetzt habe ich gezielte Performance Messungen gemacht.
Die ipv64.net Ergebnisse sind abhängig davon ob Webseite oder DynDNS.
z.B.
Aufruf der Webseite: meistens im Mittelfeld
DynDNS Update.: fast immer am langsamsten
41.1 ms L=6919 https://ipv64.net
157.4 ms L=1819 http://fonts.googleapis.com/css?family=Open+Sans:400,300,600,700
171.5 ms L=5575 https://www.berkshirehathaway.com
187.5 ms L=6802 https://www.scalemates.com
194.3 ms L=15182 https://fastestwebsite.net
199.7 ms L=8832 https://www.corewebvitals.io
246.0 ms L=9129 https://fritz.com
456.2 ms L=993 https://view-transitions.chrome.dev/profiles/mpa/
1,411.1 ms L=150 https://ipv64.net/nic/update?MY_SECRET_UPDATE_QUERY
Die Werte schwanken etwas, sind aber durchaus reproduzierbar.
Die Tendenz ist eindeutig: DynDNS Updates sind fast immer die langsamsten.
Hier noch eine Messung:
88.5 ms L=1819 http://fonts.googleapis.com/css?family=Open+Sans:400,300,600,700
125.0 ms L=5575 https://www.berkshirehathaway.com
149.4 ms L=6919 https://ip4.ipv64.net
156.3 ms L=993 https://view-transitions.chrome.dev/profiles/mpa/
177.8 ms L=15182 https://fastestwebsite.net
204.5 ms L=6983 https://www.scalemates.com
211.3 ms L=8832 https://www.corewebvitals.io
283.2 ms L=9130 https://fritz.com
482.2 ms L=6919 https://ipv64.net
1,045.7 ms L=141 https://ipv64.net/nic/update?MY_SECRET_UPDATE_QUERY
1,111.8 ms L=141 https://ip4.ipv64.net/nic/update?MY_SECRET_UPDATE_QUERY
So jetzt ist mir auch klar warum die Fritzbox immer wieder den Tag über versucht die Dynadr aufzulösen. Das hängt mit dem Reverse Proxy zusammen. Die Fritzbox überträgt meine Ipv6 zum Dynserver und bei der Abfrage erhält die Fritzbox dann die Ip vom CDN zurück. Da das nie übereinstimmen kann reagiert die Fritzbox erneut mit der Aktualisierung. Die Fehlermeldung ist da etwas wiedersprüchlich. Die kann schon aufgelöst werden nur kommt halt aus Sicht der Fritzbox die „falsche“ zurück.
Mein Verständnis ist folgendes:
- die Fritz!Box sagt zum DynDNS Provider „Mein
Domainnamefindest du unter folgende IP“ - der DynDNS Provider teilt die Welt mit „Hey Leute, sein
Domainnameist unter folgende IP zu erreichen“ - der Antwort aber vom DynDNS Provider zum Fritz!Box ist eine reine OK Meldung (*)
- nachher, versucht die Fritz!Box eine Namensauflösung (z.B. bei Google) auf die Ihm bekannte
Domainname. Wenn die Namensauflösung als Ergebnis der IP des Fritz!Box zurückmeldet ist alles im Lot. Wenn nicht, versucht die Box mit der Fehler - wie auch immer - umzugehen…
(*) die Rückmeldungen der verschiedene DynDNS Provider sind ganz unterschiedlich:
ipv64.netliefert ein JSON Datei zurück mit die IP’s, IPv6Prefix & StatusmeldungDuckDNSmeldet einfach „OK“ oder, im Fehlerfall, „KO“ddnss.deliefert eine enfache HTML Seite mit der Anzahl Domains updated
Korrekt, und woran liegt das? DynDNS ist nicht spezifiziert oder in einem richtigen RFC niedergeschrieben. Wenigstens hat man bei IPv64 noch die Option output=min oder output=full zu setzen.
Ich wurde Abfrage und Dynserver präcisieren um’s nicht mit DNS Server zu verwechseln:
das ist ein Update beim DynDNS Provider.
Danach, erfolgt eine Abfrage der IP („Namensauflösung“) beim DNS Server
(in deinem Fall, Cloudflare)
Im Allgemein erhält mann kein IP als Ergebnis der DynDNS Update.
(obwohl, im Sonderfall ipv64.net, wäre eine vorhanden)
Im Support Bericht zur Fritzbox steht drin:
IP-Soll = 1234
IP-IST = 4321
Die Fritzbox vergleicht die eigene IP mit der IP welche die Fritzbox über die Abfrage der DynDnsDomain erhält.
Und der ist nun mal verschieden und dann versucht die Fritzbox das halt immer wieder und wieder und wieder …
Es geht darum die Dinge ganz genau zu formulieren.
Wir sind hier nich Hellseher.
Das hat @The_eagle schon mal angemahnt.
„die Abfrage“ ist nichtssagend, bestens zweideutig.
@DaveTheDane
Und ich hatte mal mitgeteilt dass ich „user not programmer“ bin.
Was weiß denn ich wie die Fritzbox unter linux die Abfrage macht !!!
Ich kann damit leben.
@Dennis_Admin Zu den Connect Timeouts habe ich jetzt folgendeThese:
die scheinen nur wenn die Verbindung über IP6 aufgebaut wird vorzukommen.
Folgendes:
wenn die Fritz!Box sich in der Nacht neu verbindet, bekommt die Box neue IP’s.
Dies führt dazu, das unsere Synology NAS neue IP6 Globale Addressen bekommt:
also im Bereich 2a02:x:x:x:x:x:x:x
(auf dem Synology NAS läuft unsere DynDNS Proxy)
Die bisherige Globale Addressen bleiben eine Weile erhalten & sind so lange auf Betriebssystem Ebene verfügbar & sind dadurch auch für Java sichtbar.
Aber, Versuche eine IP6 Verbindung gezielt von diese „Leichen“ zu ipv6.ipv64.net aufzubauen bekommen eine „HTTP connect timed out“ Meldung.
Mein Vermutung ist, daß beim ersten Versuch, Java eine diese Leichen verwendet.
(der Wahl der Schnittstelle überlasse ich momentan Java, um Komplexität zu vermeiden)
Der nächste Versuch gelingt dann.
Also, es könnte daran liegen.
Aber:
was Performance betrifft, ist die /nic/update Performance deutlich langsamer als andere Websites.
(s. meine am 16. Juni gepostete Messungen)
Vielleicht ist es ganz einfach so & die Update benötigt halt so lang.
Aber die ist ein Factor 5 bis 10 langsamere als manche andere Referenzen.
Typischerweise liegt die jenseits 1 Sekunde.
Jetzt ist es mir gelungen, das Ding fest zu nageln. Meine These war korrekt:
Nach der Neuverbindung des Fritz!Box’es bekommen die Geräte im Hausnetz neue IP6 Globale Addressen (also im Bereich 2a02:x:x:x:x:x:x:x).
So weit, so gut.
Die alte Addressen bleiben eine ganze Weile erhalten, funktionieren aber nicht mehr.
Ein Versuch eine Verbindung darüber herzustellen führt zu eine:
java.net.http.HttpConnectTimeoutException("HTTP connect timed out")
Die neue Addressen sind sichtbar in Java, funktionieren aber nicht sofort.
Ein Versuch eine Verbindung darüber herzustellen führt zu eine:
java.net.ConnectException("Cannot assign requested address")
Nach 1 bis 2 Sekunden, funktionieren die neue Addressen dann.
Wenn mann nicht explizit eine Lokale Addresse für die Verbindung spezifiziert, verwendet Java offensichtlich die alte Addresse solange die neue noch nicht funktioniert.
Dies erklärt die HttpConnectTimeoutException die zu diese Forenbeitrag führte.
(das und die Performance von ipv64.net, was nachwievor ein Thema ist)
Da Java keinerlei Zustand oder Status für eine InetAddress exponiert, bleibt die einzige Workaround darüber eine bekannte Server in regelmässige Abstände zu kontaktieren, bis die neue Addresse funktioniert.