Mal wieder: Kein IPv6 bei Deutsche Glasfaser

    Zitat von ::1

    Deine WAN-Adresse scheint nochmal gewechselt zu haben (von ::71 auf ::82)? Zumindest laut keycdn-Traceroute, wenn ich dort den /48 aus deinem Paketmitschnitt eingebe. Der /48 wird offenbar auch zu deinem Anschluss geroutet.

    Ja, die IA_NA ist jetzt ::82. Und das /48 ist komplett geroutet. Ich habe sowohl 2a00:61e0:9d41:0000::/64 und 2a00:61e0:9d41:ffff::/64 getestet und es geht traffic sowohl raus als auch wieder rein.

    Zitat von ::1

    Was man bei DG so alles erlebt - von /64-Beschränkungen bis /48-Großzügigkeiten. Was ist da nur los?

    Zusammen mit DHCP Server bei 192.168.101.1 denke ich mal, dass da "Profis" am Werk sind.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von Funker

    Das macht heutzutage der LLM-Agent. Da kommt genau sowas bei raus.

    Das kann sehr gut sein. Gerade die 192.168.101.1...

    Nachdem ich das ganze für ein bisschen beobachtet habe werde ich mir überlegen wie ich DG das ganze melde. Wenn die diese Konfiguration über das gesamte Netz verteilen.... oder "modernisieren" könnte das ein echtes Problem sein.

    Wenn jede Fritz Box ein /48 anfordert (ist aber hoffentlich nicht die Werkseinstellung) kann das halt ein richtig schöner DOS für das gesamte Netz sein. Es gibt halt nur genügend /48 für ca 25% der Kunden.

    Aber erstmal möchte ich sehen ob das /48 stabil ist.

    Unabhängig davon finde ich es merkwürdig das DG 4 /32 hat, die nicht contiguous sind. Die hätten von RIPE NCC auch ein /29 (8 /32) bekommen können ohne weitere Dokumentation. Die sorgen so halt für 3 unnötige Eintrage in der ipv6 route table.

    Also laut meiner Statistik sind das die IPv6-DG-Netze:

    Code
    IPv6-Count:
2a00:1f38::/32				netname: DE-DGW-20100415			 1x /32
2a00:6020::/32				netname: DE-DGW-20130322			 1x /32
2a00:61e0::/32				netname: DE-DGW-20130326			 1x /32
2a03:fc0::/32				netname: DE-DGW-20121010			 1x /32
2a03:1d60::/32				netname: DE-DGBUSINESS-20140731		 1x /32
2a0f:f140::/29				netname: DE-DGBUSINESS-20200928		 8x /32
-----------------------------------------------------------------------
																13x /32

    Mit dieser RIPE-DB-Anfrage ermittelt:

    Webupdates
    Tool that allows to add new objects and edit or delete existing objects in the RIPE Database
    apps.db.ripe.net
    Zitat von ::1

    Also laut meiner Statistik sind das die IPv6-DG-Netze:

    Code
    IPv6-Count:
2a00:1f38::/32				netname: DE-DGW-20100415			 1x /32
2a00:6020::/32				netname: DE-DGW-20130322			 1x /32
2a00:61e0::/32				netname: DE-DGW-20130326			 1x /32
2a03:fc0::/32				netname: DE-DGW-20121010			 1x /32
2a03:1d60::/32				netname: DE-DGBUSINESS-20140731		 1x /32
2a0f:f140::/29				netname: DE-DGBUSINESS-20200928		 8x /32
-----------------------------------------------------------------------
																13x /32

    Mit dieser RIPE-DB-Anfrage ermittelt:

    https://apps.db.ripe.net/db-web-ui/quer…&types=inet6num

    2a00:1f38::/32 und 2a0f:f140::/29 scheint aber nicht announced zu werden: https://bgp.he.net/AS60294#_prefixes6

    Das letzte mal war 2a0f:f140::/29 durch AS41776 verwendet. Das war aber 2023.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von ::1

    Gibt es eine Pflicht, eigene Präfixe zu announcen, wenn diese ggf. nur einen Reserve-Status haben, also aktuell nicht genutzt werden?

    Ich denke mal nicht. Allerdings stellt sich bei Nichtbenutzung über Jahre die Frage ob dann vielleicht nicht verlängert wird:

    Zitat

    RIRs will generally renew licenses automatically, provided requesting organisations are making a “good faith” effort at meeting the criteria under which they qualified for or were granted an allocation or assignment. However, in those cases where a requesting organisation is not using the address space as intended, or is showing bad faith in following through on the associated obligation, RIRs reserve the right to not renew the license.

    Zitat

    To qualify for an initial allocation of IPv6 address space, an LIR must have a plan for making sub-allocations to other organisations and/or End Site assignments within two years.

    IPv6 Address Allocation and Assignment Policy
    ripe-738: This document defines registry policies for allocating and assigning globally unique IPv6 addresses to Internet Service Providers (ISPs) and other…
    www.ripe.net

    Aber es ist natürlich nicht so, dass ein unbenutztes /29 irgendwie entscheidend ist.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von fiberv6

    Nachdem ich das ganze für ein bisschen beobachtet habe werde ich mir überlegen wie ich DG das ganze melde.

    Auch diese "Meldung" wird nur ein KI-Chatbot lesen. Die Abteilungsleitung NOC ist übrigens vakant:

    Deutsche Glasfaser Unternehmensgruppe sucht Abteilungsleitung Network Operations Center (NOC) (w/m/d) in Borken | LinkedIn
    11:42:56 gepostet. Das treibst du voranFachliche und disziplinarische Führung des Network Operations Centers: Du…. Sehen Sie sich dieses und weitere…
    de.linkedin.com

    Echte Fachkräfte wachsen nicht auf Bäumen und suchen sich ihren Arbeitgeber aus. In den hiesigen Gefilden gehen die bevorzugt zur Telekom. Eine Zukunft bei einem Arbeitgeber, der nicht direkt von der Insolvenz bedroht ist, macht mit Häuschen und Familie auch mehr Spaß.

    Zitat von ::1

    Das sieht ehrlich gesagt nicht sonderlich "gesund" aus - ich kann allerdings ohne Tiefenanalyse von RFC9915 aktuell nicht bewerten, welche Seite hier genau was falsch macht.

    Habe ich nun mal versucht.

    Zunächst zwecks Vergleich ein Auszug aus Paket #4 mit der letzten erfolgreichen Lease-Verlängerung:

    Nun im Vergleich dazu die beiden IA-Optionen aus dem Paket #6:

    Hier sind die Renew- und Rebind-Timer (T1, T2) jeweils 0. Und anstelle der "IA address"- bw. "IA Prefix"-Sub-Optionen ist jeweils der Status Code "NoBinding" enthalten.

    Jetzt habe ich RFC9915 angeschaut, um zu eruieren, was der DHCPv6-Client in dieser Situation tun sollte:

    Fündig wird man in Section 18.2.10. Ich kopiere daraus mal (mit Weglassungen) die Textpassagen, die m. E. zutreffend sind:

    Code
    18.2.10. Receipt of Reply Messages

Upon the receipt of a valid Reply message in response to a ... Renew ... message, the client extracts the top-level Status Code option (see Section 21.13) if present.

    Kommentar: keine "top-level Status Code option" in Paket #6 enthalten

    Code
    ...

Otherwise (no status code or another status code), the client processes the Reply as described below based on the original message for which the Reply was received.

...

18.2.10.1. Reply for Solicit (with Rapid Commit), Request, Renew, or Rebind

...

    In dem Unterkapititel 18.2.10.1 heißt es nun weiter:

    Code
    If the Reply was received in response to a ... Renew ... message, the client
updates the information it has recorded about IAs from the IA options contained
in the Reply message:

  ...

    Im folgenden gibt es nun zwei Handlungsoptionen, bei denen mir nicht eindeutig klar ist, welche die zutreffende Variante ist:

    Erste Variante:

    Code
    If the Reply message contains any IAs but the client finds no usable addresses and/or delegated prefixes in any of these IAs, the client may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to obtain other configuration information only.

    Zweite Variante:

    Code
    When the client receives a Reply message in response to a Renew or Rebind message, the client:

o Sends a Request message to the server that responded if any of the IAs in 
  the Reply message contain the NoBinding status code. The client places 
  IA options in this message for all IAs.

    Die erste Variante trifft zu, wenn man den Passus "client finds no usable addresses and/or delegated prefixes" als zutreffend interpretiert, denn anstelle der "IA address"- bw. "IA Prefix"-Sub-Optionen sind jeweils die Status Codes "NoBinding" enthalten.

    Man könnte diesen Passus aber auch so interpretieren, dass zwar "IA address"- bw. "IA Prefix"-Sub-Optionen vorhanden sind, diese jedoch "Null"-Adressen enthalten (wie bei einem DHCPv6-Solicit: keine "IA address"-Option in IA_NA, "Prefix address" = :: in IA_PD).

    Weil das aber in unserem Fall nicht zutrifft, wäre bei dieser Deutung dann die zweite Variante zutreffend, die explizit auf den NoBinding-Status eingeht (erscheint mir plausibler):

    Demnach sollte der DHCPv6-Client einen Request ähnlich einem DHCPv6 Solicit senden, in dem allerdings abweichend von einem "echten" Solicit eine "Server Identifier"-Option des Servers enthalten ist, von dem Paket #6 gesendet wurde.

    Das käme im Grunde dem sofortigen Start eines neuen Exchanges (Solicit - Advertise - Request -Reply) gleich, nur eben mit keinem allgemeinen Solicit an beliebige (ungenannte) DHCPv6-Server, sondern an den einen, der zuvor Paket #6 gesendet hat.

    Dein DHCPv6-Client scheint mehr der ersten Variante zu folgen, indem er den Passus the client may either try another server (perhaps restarting the DHCP server discovery process) (zunächst) durch das Senden von DHCPv6-Rebinds umsetzt.

    Kurzer Morgen-Post: (Lese den Beitrag von ::1 später, habe nur kurz Zeit):

    Heute morgen (ca. 7:30) hat der Renewal wieder nicht funktioniert, obwohl ich hinterher wieder genau das selbe /48 Prefix bekommen habe (die WAN /128 hat sich allerdings geändert).

    Dieses mal hatte es aber tatsächlich Auswirkungen auf die Homeoffice OpenVPN Verbindung von meiner Mutter. Also das wäre tatsächlich der Fall den man auch dem Level 1 Support schildern kann und ist nicht einmal ausgedacht.

    Bin mit OpenVPN nicht so vertraut, warum läuft das als Client nicht wenn IPv6 weg ist? Muss sich das per STUN/ICE verbinden und der CGNAT ist symmetrisch? Das wäre jetzt meine schnelle Vermutung. Weil als normaler IPv4 Client sollte ja weiterhin alles funktionieren. Oder vielleicht hat der Laptop noch eine zugewiesene IPv6 und failed nicht over?

    Bin später heute allerdings wieder an dem Standort und schaue mir mal per Capture an, was der OpenVPN Client macht.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Das mit kein failover zu IPv4 wäre merkwürdig. Ich bin mir relativ sicher das die RAs den clients bei dem gefailten Renewal klar machen das keine IPv6 default route mehr da ist. Zumindest mein Linux smokeping kriegt es mit (Uhrzeit in UTC):

    Kein packet loss, über die 30 Minuten (in denen mein DHCP Server leider nicht gleich den neuen solicit started), sondern halt keine Verbindung. Bei 100% packet loss währe das rot markiert.

    Als Vergleich hier smokeping für IPv4 in dem Zeitraum:

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von ::1

    Zweite Variante:

    Code
    When the client receives a Reply message in response to a Renew or Rebind message, the client:

o Sends a Request message to the server that responded if any of the IAs in 
  the Reply message contain the NoBinding status code. The client places 
  IA options in this message for all IAs.

    Ich habe nochmal intensiv RFC9915 gelesen. Und ich lese es so, dass Variante 2 die richtige ist. Hauptsächlich, weil die spezifischer den vorliegenden Fall beschreibt. Variante 1 lese ich mehr als "catch-all".

    Lese gerade den Quellcode für systemd-netword um festzustellen wie das intern genau funktioniert in diesem Fall.

    Und wenn ich es korrekt verstehe kann mein Client die IA_NA und IA_PD währenddessen auch noch weiter verwenden, da die lifetime ja nicht auf 0 gesetzt ist. Lediglich T1 und T2 sind 0. Lifetime ist gar nicht vorhanden.

    Das Verhalten des DHCPv6 Servers bleibt immer noch seltsam. Warum dieses Spiel mit NoBinding, nur um mir immer noch das selbe /48 zu geben und lediglich die IA_NA zu ändern (immer noch aus dem selben /64).

    Zitat von fiberv6

    Das Verhalten des DHCPv6 Servers bleibt immer noch seltsam. Warum dieses Spiel mit NoBinding,

    Ja, ich frage mich auch, ob das der mustergültige Weg für die Zuteilung neuer IPv6-Adressen ist.

    Als Antwort auf den Rebind könnte der DHCPv6-Server in den IA-Optionen die alten Adressen bestätigen, allerdings deren Timer-Werte für Preferred und Valid Lifetime auf 0 setzen. Damit würden sie für den DHCPv6-Client sofort ungültig und er muss sie entfernen.

    Zugleich könnte der DHCPv6-Server zwei zusätzliche IA-Optionen (IA_NA und IA_PD) mit neuen Adressdaten ergänzen.

    Das erscheint mir als der bessere Weg.

    Oder man bedient den Reconfigure-Weg, nur fürchte ich diesbezüglich mangelnde Unterstützung auf Home-Router-Seite.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von ::1

    Ja, ich frage mich auch, ob das der mustergültige Weg für die Zuteilung neuer IPv6-Adressen ist.

    Zumahl heute morgen ja das Präfix nichtmal geändert wurde. Warum also NoBinding für IA_PD? Macht überhaupt keinen Sinn. Und die zufälligen Uhrzeiten und Zeitabstände in denen das passiert.

    Ich glaube nicht, dass das tatsächlich ein absichtliches Verhalten ist.

    Ich werde später heute entweder wide dhcpv6 oder odhcp ausprobieren. Obwohl ich gerne nochmal aufgenommen hätte welche RAs mein Router in den 30 Minuten auf LAN Seite sendet. Sehr nervig für jedes Experiment 1 bis 7 Tage warten zu müssen.

    Looking through the source of systemd-networkd 255 actually basically ignores the IA completely with the NoBinding. That's why it gets stuck in this rebind loop for 30 minutes. It's acting like it didn't get a response at all.

    Current main branch systemd-networkd should go into a completely new SOLICIT based on the source.

    dhcpcd looks to actually follow our expectations exactly. It should be doing a REQUEST for all IAs.

    (lol, sorry für Englisch, passiert mir manchmal automatisch)

    Werde mal dhcpcd testen.