Beiträge von ::1

Zitat von dgfeuer

Hatte gestern noch die FritzBox Fiber zum testen dran.

Naja, zuviele Wechsel Ubiquiti -> Fritzbox -> Win-PC, da ist der DHCPv6-Server der DG schnell mal beleidigt ...

Aber, wenn du schon eine FB zum Testen hast - dann hänge die doch nach gebührlicher Warte-Zeit mal wieder dran. Und wenn die dann wieder IPv6 bekommt, ohne dass IPv6-Kommunikation mit dem Internet anschließend tatsächlich funktioniert, dann mach doch bitte mal einen Paketmitschnitt in der FB (Browser-Tab 1: Hilfe und Info | FRITZ!Box Support | Paketmitschnitt | 1. Internetverbindung - Start), während du in einem Browser-Tab 2 unter "Internet | Online-Monitor | Verbindungsdetails" die Schaltfläche "Neu verbinden" betätigst und nach Erhalt der IPv6-Adresse(-n) noch einen Ping zu einem IPv6-Ziel im Internet von einem LAN-Client aus durchführst.

Mein Angebot, mir den Mitschnitt, den du mir per Privat-Konversation zuschicken kannst, anzuschauen, steht immer noch.

Zitat von frank_m

Das ist im Heimnetz ja eher unüblich, da kommen Router-Advertisements zum Einsatz.

<KLUGSCHEISS>

Außer in routerlosen Netzen kommen die immer zum Einsatz, auch wenn man die Clients im Netz ausschließlich per DHCPv6 konfigurieren möchte:

• Das IPv6-Standardgateway wird per RA gelernt. Anders als bei DHCP gibt es bei DHCPv6 keine Option für das Standardgateway.
• Das LAN-Präfix kommt per PIO im RA, DHCPv6 vergibt nur 128-Bit-Adressen. Es gibt bei DHCPv6 keine Option für die Präfix-Länge (bei DHCP gibt es hingegen eine Option für die IPv4-Subnetz-Maske)

Ob LAN-Clients per SLAAC oder per DHCPv6 IPv6-Adressen bekommen, muss über die Konfiguration der M/O-Flags in den RA gesteuert werden (M=1: DHCPv6, M=0,O=1: SLAAC und zusätzliche Daten (z.B. DNS-Serveradressen) via stateless DHCPv6 + ggf. RA-Optionen, M=0,O=0: SLAAC und zusätzliche Parameter ausschließlich via RA-Optionen)

</KLUGSCHEISS>

Windows würde nach mittels DHCPv6 fragen, wenn es vom DG-Router ein RA erhält, in dem das M-Flag gesetzt ist (Windows versucht das aber nach der ihm eigenen Art auch ohne das).

Es muss nach Abklemmen des Routers aber mindestens eine Stunde gewartet werden, ehe man irgendetwas anderes anklemmt, sei es einen PC oder einen anderen Router.

Wir reden aneinander vorbei: Du redest vom LAN-internen Gateway für deine Clients im LAN - Das ist die fe80-Adresse am LAN-Interface deiner Ubiquiti.

Ich rede vom Gateway der DG. Das ist der Default-Router, den deine Ubiquiti verwendet, um IPv6-Pakete über das WAN-Interface ins Internet zu schicken. Der steht in der Routingtabelle deiner Ubiquiti als next hop für den Default-Eintrag ::/0.

Kannst du den auslesen? Sollte ebenfalls eine fe80-Adresse sein.

DG Gateway ist auch vorhanden 2a00:6020:......./64

Das wäre dann der Fehler: Das DG-Gateway wird dynamisch aus den RA gelernt, die es zu deinem WAN-Port sendet. Es muss folglich eine fe80-Adresse sein. Es gibt lediglich eine globale /128-Adresse 2a00:6020:..../128 für deinen WAN-Port (zugeordnet per DHCPv6) und kein /64-Netz, weil im RA keine PIO vorhanden ist.

Kannst du in deiner Ubiquiti nachschauen, ob eine IPv6-Defaultroute (::/0) vorhanden ist, und wie die DG-Gateway-Adresse lautet (sollte mit fe80 beginnen)?

Kannst du ferner den IPv6-Neighbor-Cache für das WAN-Interface der Ubiquiti anschauen, ob dort ein Eintrag für das DG-Gateway vorhanden ist?

Falls du am WAN-Port ein Packet-Capture machen kannst, während die IPv6-Verbindung zu DG aufgebaut wird (z.B. nach einer Reinitialisierung des WAN-Interface), dann kann ich dir anbieten, mir die Capture-Datei zwecks Analyse per Privat-Konversation zuzuschicken.

Zitat

Jetzt möchte man mir einen Technikereinsatz für 80€ berechnen sollte dies mein verschulten gewesen sein.

Na, ist doch super! Da es nicht dein Verschulden ist, hast du ja nichts zu befürchten. Und du bekommst dediziert einen Techniker, der sich deines Problems annimmt.

Fragt sich nur, was der macht, wenn er vor Ort kommt - wenn er nur die "Leitung prüft", im Sinne von physischer Konnektivität (die ist ja vorhanden), sich aber nicht weiter für die Prüfung der Verfügbarkeit/Nutzbarkeit von IPv6 interessiert, dann bist du angeschmiert und darfst zahlen. Deshalb würde ich bei Anforderung des Technikers genau definieren, was der prüfen/beheben soll, nämlich deine IPv6-Konnektivität - der Rest funktioniert ja.

Es ist auch hier auffällig, wie in ähnlich gelagerten, im Forum diskutierten Fällen, dass das Problem in einem BNG-IPv6-Range auftritt, in dem DG offenbar ein geändertes IPv6-Adressierungsschema verwendet.

Es handelt sich dabei um Blöcke

2a00:6020:XYZ0::/41 (Z=0 oder Z=8, hier 2a00:6020:8f00::/41), in denen die WAN-Port-Adresse aus 2a00:6020:XYZ0::/112 (hier 2a00:6020:8f00::/112) vergeben wird.

In anderen Bestandsblöcken 2a00:6020:XYZ0::/41 (Z=0 oder Z=8) älterer Art werden WAN-Port-Adressen hingehen stets aus 2a00:6020:1000:PQ::/112 zugeordnet, wobei PQ für jedes XYZ einen separaten Wert hat. Ich hatte das in #10 mal näher beschrieben.

Im neuen Adressierungsschema scheint es gelegentlich noch zu haken.

Auch hier muss ich wieder viel rätseln und mir meinen Reim selbst drauf machen:

Der Traceroute erfolgt also an einem Windows-Client im LAN 2a00:6020:8f41:cd00::/64 hinter einer Fritzbox mit der LAN-Adresse 2a00:6020:8f41:cd00:b6fc:7dff:fe41:cf9b (OUI b4:fc:7d = AVM).

Die Fritzbox hängt aber wohl nicht direkt am DG-Anschluss, sondern hinter deiner Ubiquity an deren LAN-Port mit der Adresse fe80::2870:4eff:ff84:1c22 (OUI 28:70:4e = Ubiquity).

In der Ubiquity hast du für IPv6 eine Prefix-Delegation 2a00:6020:8f41:cd00::/64 an die Fritzbox definiert. (Nebenbei: Existiert in der Ubiquity dafür auch eine Route zur Fritzbox mit next hop = WAN-Interace-IPv6 der Fritzbox? Welches IPv6-Netz ist denn für den WAN-Uplink deiner Fritzbox zur Ubiquity konfiguriert?)

Daraus folgt, dass deine Ubiquity am DG-Anschluss ihrerseits von der DG wohl den PD-Block 2a00:6020:8f41:cd00::/56 zugewiesen bekommen hat. Das liegt im Range 2a00:6020:8f00::/41 - einem der neueren Ranges, bei denen DG auch ein neues IPv6-Adressierungskonzept verwendet. Die WAN-Port-Adresse müsste dort in 2a00:6020:8f00::/112 liegen, bei dir also 2a00:6020:8f00::df, wenn ich es richtig sehe.

Nochmal zum Traceroute: Wenn meine Deutung richtig ist, ist Hop 2 (fc00::1) nicht die DG sondern dein Ubiquity-Router?

Wie wär's, wenn du erstmal die IPv6-Funktion mit einem Client direkt in einem LAN hinter der Ubiquity testest?

Zitat von dgfeuer

Ich wüssete gerne mal wie ihr das Problem beschrieben habt.

Was ist denn genau dein Problem?

Deinen ersten beiden Meldungen (#50, #138)

Zitat

Bei mir das gleiche Problem ipv6 von extern nicht erreichbar.

...

tracert -6 ipv6.google.com

endet mit dem 2. Hop auf fc00::1

und

Zitat

Habe ebenfalls Intern keine ipv6 trotz korrekten Einstellungen

Trace 2. Hop fc00::1

würde ich entnehmen, dass bei deinem Anschluss gar keine IPv6-Kommunikation (weder outbound noch inbound) möglich ist. Bzw. hast du evtl. noch nicht mal IPv6-Adressen zugewiesen bekommen (WAN-Adresse + LAN-PD-Block)?

Alles etwas dünn, um hierzu etwas sagen zu können.

Zitat von Glasgau

Habe außer: Username, Passwort,Registrar nichts zum Eintragen

Ist merkwürdig - in meiner FB7590 (auch aktuelle Version 8.03) sehe ich nach Umstellung eines in der FB vordefinierten Telefonie-Anbieter-Profils (in meinem Fall "Deutsche Glasfaser" und "dus.net") auf "Anders Anbieter" stets die vollständigen Detail-Einstellungen des jeweiligen Anbieters. Nach Vornahme einer Änderung und deren Speicherung wird mir dann wieder die reduzierte Sicht des jeweiligen Telefonie-Anbieters angezeigt.

Vielleicht machst du doch mal einen Werks-Reset deiner Fritzbox und konfigurierst nochmal alles "from the scratch".

Zitat von Glasgau

So DG hat mir eben mitgeteilt ich soll mal das Modem reseten.

Eine erwartungsgemäße Ansage, dem Problem total angemessen!

Kontrolliere bitte nochmal im DG-Kundenportal unter "Meine Telefonie | Meine Rufnummern", ob dort deine Rufnummer(-n) deinem(-n) SIP-Account(s) (dort ohne die führende "3050" dargestellt) korrekt zugeordnet ist/sind.

Zitat von ::1

dg.voip.dg-w.de löst übrigens nur nach IPv4 auf: 185.22.44.186.

Ich würde deshalb bei "Internettelefonie-Anbieter kontaktieren über" explizit mal "Nur via IPv4" einstellen.

Vergiss das bitte.

Der Ablauf zur Registrierung erfolgt über einen DNS-Query

des Typs SRV für _sip._udp.dg.voip.dg-w.de

wie folgt (hier mit NSLOOKUP nachgestellt):

C:\>nslookup - 185.22.44.50
Standardserver:  dnscache001.dg-w.de
Address:  185.22.44.50

> set q=SRV
> _sip._udp.dg.voip.dg-w.de
Server:  dnscache001.dg-w.de
Address:  185.22.44.50

Nicht autorisierende Antwort:
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 20
          weight         = 1
          port           = 5060
          svr hostname   = sip20.voip.dg-w.de
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 10
          weight         = 1
          port           = 5060
          svr hostname   = sip10.voip.dg-w.de
> set q=A+AAAA
> sip20.voip.dg-w.de
Server:  dnscache001.dg-w.de
Address:  185.22.44.50

Nicht autorisierende Antwort:
Name:    sip20.voip.dg-w.de
Addresses:  2a00:6020:200:603::165
          185.22.45.165

> sip10.voip.dg-w.de
Server:  dnscache001.dg-w.de
Address:  185.22.44.50

Nicht autorisierende Antwort:
Name:    sip10.voip.dg-w.de
Addresses:  2a00:6020:100:603::186
          185.22.44.186

>

Die Registrierung kann also sowohl via IPv4 als auch via IPv6 zu sip10 oder sip20 erfolgen. Registrierungen via IPv6 und Telefonie via IPv6 habe ich auch schon in Paketmitschnitten an meinem Fritzbox-WAN-Port gesehen.

dg.voip.dg-w.de löst übrigens nur nach IPv4 auf: 185.22.44.186.

Ich würde deshalb bei "Internettelefonie-Anbieter kontaktieren über" explizit mal "Nur via IPv4" einstellen.

Zitat von Glasgau

Ich komme nicht zur Registrar. Sobald ich bei Anbieter, über andere Anbieter, die DG angebe, kann ich nur Username und Passwort eingeben.

Mehr kommt da nicht. Oder wo könnte ich das noch eingeben?

Der Registrar und weitere Einstellungen sind implizit durch Wahl des Telefonie-Anbieters "Deutsche Glasfaser" in der Box vordefiniert. Du kannst diese Daten sichtbar machen, indem du bei "Telefonie-Anbieter" auf "Andere Anbieter" umstellst.

Zitat von DaSokas

Mich macht das schon etwas stutzig, was die genauen Unterschiede sind.

Ich bin immer noch nicht ganz weg von der Idee interface-bezogener Filter bei der Palo, die den ND-Traffic reglementieren ...

Siehe meine Anmerkungen in #131.

Zitat von Neurothiker

Ich habe auf den Schnittstellen LAN&WAN v6 deaktiviert - wie ich aber schonsagte, kann es sein, dass die neu hinzugefügten Schnittstellen vlan&PPPoE v6 nutzen. Da muss ich, wenn das Frontend wieder nutzbar ist(derzeit eingefroren), nachschauen.

Da könnte ein Packet-Capture am Client helfen. Aus dem ginge hervor, welchen Resolver er verwendet.

Also, wenn dein Client beliebige Internet-FQDNs per DNS auflösen kann (kann er?), die zugehörigen DNS-Requests jedoch in deinem UNBOUND-Log nicht auftauchen, dann liegt der Verdacht nahe, dass dein Client unter Umgehung des UNBOUND einen anderen Resolver verwenden kann (über ein anderes Interface und/oder via IPv6 statt IPv4).

Also der Client hat nur eine IPv4-Adresse, aber keine IPv6-Adresse?

Und die IPv4-Adresse des per DHCP-Option erhaltenen DNS-Servers entspricht *.140.1?

Ich frage nur, um herauszufinden, ob der Client evtl. noch einen anderen Resolver anstelle des UNBOUND fragen könnte, z.B. via IPv6 und somit ggf. deinen UNBOUND umgehen könnte.

Zitat von Neurothiker

...kein Client mehr

Und der Testclient hat welche Resolver-Adesse(n) per DHCP/DHCPv6 bzw. ggf. SLAAC erhalten? sind das die LAN-seitigen UNBOUND-Adressen?

Ok, hat sich jetzt überschnitten. Wenn man dir jetzt eine öffentliche IPv4-Adresse geben konnte, dann hast du offensichtlich kein DS-Lite. Dann kannst du meinen letzten Post ignorieren.