Ich habe z.B. an meinem Anschluss NAT64 als Übergangsmechanismus in die alte Welt.
Hallo, nur interessehalber:
Das ist vermutlich ein Eigenbau-NAT64 (mit zugehörigem DNS64)?
Oder ist das tatsächlich eine Dienstleistung deines ISP, weil der nur noch IPv6-only-Anschlüsse anbietet?
Sascha.F : Der Link zur JPG zeigt leider kein Bild ...
Aber ja, was für ein Armutszeugnis seitens DG.
Das wird sich mit IPv6 nicht grundsätzlich ändern.
Hm, naja, angesichts der üblicherweise verwendeten Privacy-Extensions an Endgeräten hinter Consumer-Zugängen macht ein Blockieren einzelner IPv6-Adressen (hierzu gefunden: "UCEPROTECT Blacklist Policy LEVEL 1", siehe hier) nun wirklich keinen Sinn, da hoffe ich dann auch auf "vernünftige" Sichtweisen. Wenn schon, müsste man da gleich den zugehörigen /56 des PD-Blocks (Level 2) als Pendant zur geblockten IPv4-Adresse am WAN-Port des Internet-Zugangsrouters (sofern noch öffentlich) bzw. zur CGNAT-Adresse in die BL aufnehmen. Das hielte ich gelinde gesagt für sehr gewagt.
Das "deshalb" bezog sich darauf, dass Web.de und GMX den Kunden anhand der Login-Daten einwandfrei identifizieren können und nicht darauf angewiesen sind, ihn per DNSBL in Sippenhaft zu nehmen. Eine IP-Adress-Sperre ist dann so, als würde man sagen: "Wir wissen zwar, wer du bist, aber wir blocken dich trotzdem, weil der da drüben dich nicht kennt." Das erscheint mir nicht vernünftig.
Dir mag das nicht vernünftig erscheinen, aber woher weißt du, dass GMX/web.de genauso vernünftig sind wie du?
Sehr viele IP-Adressblöcke von Access Providern stehen auf DNSBLs. Das trifft auch auf Adressbereiche zu, die nicht für CGNAT verwendet werden.
Ok, auch an einem "vollwertigen" IPv4-Consumer-Anschluss (z.B. der Telekom) kann ich eine IPv4-Adresse zugewiesen bekommen, die durch Missbrauch des Vorbesitzers (der ggf. als Opfer bzw. Teil eines Bot-Netzes gar nichts davon wusste) auf eine BL gekommen ist. Aber die Wahrscheinlichkeit, dass mich solch eine Blockade trifft, ist mit einer CGNAT-Adresse doch ungleich größer, weil der ja eben in der Regel deutlich kleiner ist als der Access-Pool eines großen Providers wie Telekom, der jedem Kunden immer noch den Luxus einer eigenen öffentlichen IPv4-Adresse aus einem Riesen-Pool bieten kann. Ein /18 der DG enspricht 2^14=16384 CGNAT-Adressen - der Access-Pool der Telekom ist da sicherlich um einige Größenordnungen größer.
Eine IP-Adress-Sperre erscheint mir deshalb wenig sinnvoll und das eigentliche Problem zu sein, und nicht etwa, dass du eine Verbindung mit CGNAT nutzt.
Nun ja, CGNAT-Adressen der DG liegen im Block 94.31.64.0/18. RIPEstat sagt dazu (siehe hier) :
94.31.64.0/18 has been found in RECENT blocklists
Wenn das VPN mit IPv6 als Transportprotokoll auf dem Lancom hinter der Fritzbox terminieren soll, dann reicht es, wenn der Lancom eine IPv6 Adresse von der Fritzbox bekommt, was in der Voreinstellung ohne PD der Fall sein sollte.
Das ist wahrscheinlich die beste, weil stabilste (kein hinderliches NAT) Lösung:
Man muss ja auch keine site-to-site-Kopplung vom LANCOM-Router zur heimischen Fritzbox als VPN-Peer via IPv6-Transport herstellen (was seitens der Fritzbox vermutlich ohnehin nicht unterstützt würde). Es würde ja reichen, eine client-to-site VPN-Verbindung von einem VPN-Client auf einem IPv6 sprechenden PC im Heimnetz zur IPv6-Adresse des LANCOM-WAN-Ports aufzubauen.
Voraussetzungen:
Verständnisfragen zur Ausgangssituation:
Ich vermute mal, dass IPv6 im Firmennetz nicht von Interesse ist - das soll alles weiter laufen wie gehabt mit IPv4-only?
Wie ist der LANCOM-Router konfiguriert? Exakt wie vorher, als an seinem WAN-Port noch direkt das Internet hing - jetzt nur mit dem Unterschied, dass die WAN-IP eine private Adresse aus dem Fritzbox-LAN ist? Das würde dann ja bedeuten, dass der LANCOM seinerseits ein (ausschließlicher) NAT- bzw. PAT-Router ist, der ausgehend das 10er-Firmennetz auf die eine IP-Adresse am WAN-Port nattet. In Summe wäre das dann ein Triple-NAT zum Internet.
Hi,
ich weiß jetzt nicht, ob die "FritzBox-FritzBox-VPN-Verbindung" mit IPv6 als Transport-Protokoll durch das Internet unterstützt wird. Wenn das nur mit IPv4 möglich ist, kann ich mir ihr Zustandekommen nur dadurch erklären, dass die heimische Fritzbox an einem Internet-Anschluss hängt, die noch eine öffentliche IPv4-Adresse am WAN-Port bekommt - dann kann zumindest von der Fritzbox am DG-Anschluss eine Verbindung über CGNAT hinweg (mittels NAT-Traversal) zur heimischen Fritzbox aufgebaut werden, aber nicht umgekehrt.
Dass nun das 10er-Firmennetz hinter der LANCOM-Box nicht erreicht wird, könnte an zwei Dingen liegen:
EDIT - zu den letzten beiden Punkten, falls zutreffend noch eine Idee als Workaround: Man könnte den LANCOM-Router als IPv4-NAT-Router konfigurieren, und einzelne IPv4-Adressen im 192.168.x.x-Netz der Firma als "Einwärts"-Dienstadressen zu definieren, die ins 10er-Firmennetz genattet werden zu 10er-Adressen von Diensten, die von außen durch den VPN-Tunnel angesprochen werden sollen.
Wow, so viel Resonanz auf meine Frage hätte ich gar nicht erwartet!
Danke für die guten Erklärungen - "again what learned" 
Aus eigenen Erfahrung weiß ich, dass das Hosten von mehreren Webseiten mit verschieden IPv6 Adressen deutlich aufwendiger ist als eine IPv4 Adresse für 50 und mehr Webseiten zu hosten. Das liegt daran, dass Bind es für IPv4 out-of-the-Box macht. Dasselbe mit IPv6 Adressen ist schon verwaltungsmäßig deutlich aufwendiger.
Nur interessehalber- ist nicht mein Fachgebiet:
Welche Zauberfunktion besitzt denn Bind (ich verstehe darunter die bekannte DNS-Server-Implementierung), um über die Auflösung von N (N>50) FQDNs verschiedener Webpräsenzen auf die immerselbe IPv4-Adresse hinaus zur richtigen Webpräsenz zu "routen"? Für mich liegt das etwas außerhalb des Scopes eines DNS-Servers bzw. des DNS-Funktionskonzepts.
Ich verstehe ja, dass es irgendeine Instanz geben muss, die anhand der den jeweiligen FQDN beinhaltenden Aufruf-URL entscheidet, welche Web-Präsenz zu präsentieren ist, hätte diese Instanz jetzt aber nicht im DNS-Server verortet.
So ein Forum basiert auf einen engagierten Betreiber, da er kein Gewinn damit erzielt (ein hoch auf die Webefreiheit dieser Seite), wird er sich kaum einen Management-Server bei Wehost.One zulegen. Und unter dem gibt es kein IPv6 für den Server.
Ok, angesichts dessen braucht man nun wahrlich kein IPv6 zu fordern und sollte sich freuen, dass es dieses wertvolle Forum überhaupt gibt! Danke für die Recherche!
Aus ökonomischer Sicht wundert mich die Angebotsgestaltung von WebhostOne allerdings schon: Das knappe Gut "IPv4_Adresse" ist der Standard in den günstigsten Angeboten, das überreichlich vorhandene Gut "IPv6_Adresse" gibt es hingegen nur gegen Aufpreis? Hetzner macht das m.W. genau anders herum und aus meiner Sicht irgendwie richtiger - aber gut, ich bin kein Ökonom und muss das nicht verstehen.
Zur Orientierung: Wenn man IPv4-Adressen kaufen möchte, zahlt man aktuell etwa 50-55 USD pro Adresse, siehe z.B. hier. Auch interessant, wie viel Bewegung da im Markt ist - die Broker verdienen daran sicherlich prächtig.
Ein Smiley hätte wahrscheinlich schon Wunder gewirkt, du weißt ja: beim Schreiben im Netz ist der Gesichtsausdruck des schreibenden immer schlecht zu sehen
Ja, absolut! Hätte ich besser wissen müssen. Sowas ist immer etwas gefährlich und kann nach hinten losgehen. Das Bildchen machte mal auf einem RIPE-Meeting die Runde (war glaube ich Ripe69) und wurde da als Aufkleber verteilt - habe noch ein paar davon im Schub.
Ja, natürlich war meine Eröffnung bewusst etwas provokativ - sie hätte eigentlich ein wenig mit Augenzwinkern verstanden werden sollen. Die Schimpfe muss ich nun halt aushalten.
Sorry für den Eimer Wasser, den du abbekommen hast, der aber wohl mir gegolten hat.
Meine Anregung ist aber sehr wohl konstruktiv gemeint: Eine IPv6-Erreichbarkeit würde diesem Forum sehr gut zu Gesicht stehen.
das Thema ist inzwischen DG intern bekannt und wir früher oder später angegangen.
Hallo cyan DG, danke für das Statement!
Es wäre natürlich abstrakt betrachtet schöner mit IPv6-Erreichbarkeit
... nicht nur abstrakt, sondern auch ganz konkret.
Eine NAT-freie (=native) Ende-zu-Ende-Verbindung (vom Client zum Server) mit IPv6 (und das geht an Privatanschlüssen eben nur mit IPv6) ist nun mal gegenüber Doppel-NAT (NAT444) mit IPv4 (z.B. DG mit CGNAT und provider-shared Adresse (aus 100.64.0.0/10) am WAN-Port der Kunden-Router) oder Einfach-NAT (NAT44) an einem Internet-Zugangs-Router mit öffentlicher IPv4-Adresse am WAN-Port (z.B. Telekom) immer die bessere Wahl.
Beispiel mit CGNAT:
Kürzlich wurde mir von GMX und Web.de (die sind offenbar derselbe Wein in zwei verschiedenen Schläuchen) für 24h verboten, meine Mails abzurufen bzw. mich beim Webmailer anzumelden. Grund: Von "meiner" IP-Adresse würden zu viele Spam-Mails gesendet. "Meine" IP-Adresse ist natürlich die IPv4-CGNAT-Adresse meines Providers (DG), und so werden alle DG-Kunden hinter dieser Adresse in "Sippenhaft" genommen für den einen unter ihnen, der eine Spam-Schleuder ist (und ich bin mir da recht sicher, dass nicht ich derjenige bin). Und das ist nur ein Beispiel. Weitere "Issues" kann man hier und auch hier nachlesen.
Ich sprach auch nicht von "reinen" (im Sinne von "kein IPv4"), sondern von Internet-Zugängen mit "nativem" IPv6 und meinte damit, dass IPv4 auch dabei ist, nur eben "nicht-nativ", s.o.
Natürlich ist klar, dass man heute IPv4 auch noch braucht - eben weil viele Service-Anbieter immer noch nicht den "Hintern" hoch gekriegt haben, und ihre Services neben IPv4 auch über IPv6 anbieten. Das "auch" ist hier wichtig, um endlich die Migration zu IPv6 weiter voran zu bringen (und in einer noch ferneren Zukunft IPv4 dann endlich abschalten zu können). Der empfohlene Weg zu IPv6 führt über eine Dual-Stack-Phase, Transition-Technologien (z.B. NAT64) haben alle ihre Schattenseiten.
Es ist erstaunlich, wie viele namhafte Website-Betreiber auch im Jahre 2022 ihre Services immer noch nur über IPv4 anbieten - aber das ist ja auch ein physikalisches Gesetz: "Ein Service-Anbieter verharrt im Zustand der Ruhe oder gleichförmigen Bewegung, wenn keine äußere Kraft auf ihn einwirkt" (ich habe mir hier die Freiheit genommen, "Körper" durch "Service-Anbieter" zu ersetzen).
Mein Beitrag soll wenigstens einen kleinen Impuls dieser "äußeren Kraft" darstellen.
Ein Forum, das ein technisch an vorderster Front zu positionierendes Thema zum Gegenstand hat, aber nur mit Legacy-IPv4 erreichbar ist? 
Internet-Nutzer, die von ihrem ISP nativ nur noch IPv6 erhalten, würden sich über eine IPv6-Erreichbarkeit des Glasfaser-Forums sicherlich freuen!
>nslookup
Standardserver: localhost
Address: ::1
> set q=A+AAAA
> www.glasfaserforum.de
Server: localhost
Address: ::1
Nicht autorisierende Antwort:
Name: www.glasfaserforum.de
Address: 89.107.187.146
Exactly!
Generell scheitern Daten-Abrufe mit den Calls
- https://kundenportal.deutsche-glasfaser.de/api/customer/sipAccounts
- https://kundenportal.deutsche-glasfaser.de/api/customer/phoneNumbers
- https://kundenportal.deutsche-glasfaser.de/api/customer/personalInfo
und damit alle davon abhängigen Darstellungs-Optionen. Man kann auch keinen E-Mail-Account anlegen, weil die Funktionsschalter dafür nicht angezeigt werden.
Ich vermute mal, unsere Kunden-Datensätze in deren Backend-DB sind teilweise "kaputt".
Immerhin kann man noch die Monatsrechnungen abrufen ...
ich habe auch genau diese Probleme seit Mitte Mai 2022.
Na, da bin ich ja froh, nicht der einzige mit diesem Problem zu sein. Exakt so sieht es auch bei mir aus, danke für die vielen Screenshots!
Und der Service reagierte in meinem Fall vermutlich auch nur, weil ich mangels Einstellmöglichkeit (Rufnummernzuordnung) mit Kündigung der zweiten Telefonleitung (=2. SIP-Account) drohte.
Die Version des Portals (zumindest die im Web-Browser aufgerufene) hat sich jetzt zwar auf 34.3.0 erhöht, bringt aber leider keine Besserung.
Warten wir also ab und hoffen das beste.
Oder es ist doch ein individuelles Problem bei dir. Nutzt du Werbeblocker, Script-Blocker oder aggressive Sicherheitssoftware?
Ja, mit meinem FF-Browser nutze ich einen Werbe-Blocker, aber wie ich oben schrieb, habe ich den Portal-Zugriff auch mit anderen Browsern und an diversen Rechnern ohne derlei Blocker probiert. Und schlussendlich zeigen sich die Fehler browser-unabhängig ja auch in der MeinDG-App am Smartphone. Aus meiner Sicht ist die Wahrscheinlichkeit für ein Problem auf meiner Seite daher sehr gering. DG bestätigte mir ja auch ein Problem mit dem Portal auf deren Seite. Vielleicht gibt's da ja für einzelne Kunden Zugriffsprobleme auf die Kundendatenbank im Backend.
Hallo,
danke für die Rückmeldungen!
Dann scheint das wohl ein Problem zu sein, das nur bei einigen DG-Kunden auftritt.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
