Dann versuche ich mal zu helfen.

Zunächst muss man verstehen, dass es die Möglichkeit gibt IPv6-Adresse nach einem festgelegten Schema zu verkürzen (siehe https://datatracker.ietf.org/doc/html/rfc4291#section-2.2). Statt

2001:DB8:0000:0000:0008:8000:200C:417A oder 0000:0000:0000:0000:0000:0000:0000:1

schreibt man dann komprimiert

2001:DB8::8:800:200C:417A oder ::1 

Das heißt konkret:

1. Führende Nullen werden weggelassen: 0008 → 8
2. Blöcke mit nur Nullen werden komplett leer gelassen: :0000: → ::
3. Aufeinanderfolgende, leere Blöcke werden ebenso zusammengefasst: :::: → ::

Die zweite Sache, die man verstehen muss ist die Kennzeichnung für Netzwerke (https://datatracker.ietf.org/doc/html/rfc4291#section-2.3). In den Beispielen oben haben wir immer genau eine Adresse genommen, will man aber ein Netzwerk definieren, so muss man ja einen Block von Adressen spezifizieren. Hier schreibt man hinter die Adresse einen Slash (/) und die Anzahl der Bits von vorne, die fix sind. Zum Beispiel

2001:0DB8:0:CD30::/64

Die ersten 64 Bit sind festgelegt, jeder Block hat 16 Bit, also sind die ersten vier Blöcke fix.

Schaut man jetzt in die Liste der IANA (https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml), so findet man den Eintrag:

::/8     Reserved by IETF

Ich verstehe das so: Alles was mit den ersten acht Bit gleich “0” anfängt ist von der IETF reserviert. Oder aufgedröselt, jede Adresse die dem folgen Schema entspricht:

00xx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

Und da fällt ja 0000:: nach meiner Auffassung rein. Daher sollte nur die IETF Adressen in diesem Bereich vergeben. Die einzigen, mir bekannten Adressen sind in https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml gelistet: Die Unspecified Address (alles Null) und die Loopback-Adresse (ganz hinten eine 1).

Meiner Meinung nach gilt daher: 0000::-Adressen sind zwar gültig, dürfen aber nicht einfach so von jedem benutzt werden. Insofern hat der Kollege recht, insbesondere mit der Einschränkung “bei bestimmten Begebenheiten” - dies schließt IMHO DHCP nicht mit ein. :)

Hope that helps.

​@Tumblebit, danke für den Hinweis auf die 16 bit je Block. War mir durchgerutscht heute früh. Wenn ich das Ruleset wie folgt anpasse:

ip6 saddr { fe80::/10, 0:80fe::/32 } ip6 daddr { fe80::/10, 0:80fe::/32 } udp sport 547 udp dport 546 accept

ist alles korrekt (wenn auch unschön). Mal sehen, ob der Workaround damit soweit funktioniert. Eigentlich muss das Problem aber an anderer Stelle gelöst werden.

Ich war mir nicht sicher, ob das Problem nicht doch bei mir liegt, weil es nach einem Server-Neustart ja bislang immer erstmal funktioniert. Kann aber auch Zufall sein.

Guten Abend zusammen \o/ 

Ein kurzes Lebenszeichen von mir, ich hab mich nicht aus dem Staub gemacht, es gibt mich noch 

Wir haben jetzt an den richtigen Türen geklopft, es hat halt bei diesem crazy Fehlerbild etwas gedauert, bis wir jemanden gefunden hatten, der uns weiterhelfen konnte  

Gute Nachricht zuerst: Die Kolleg:innen konnten den Fehler jetzt dieses mal tatsächlich nachstellen und reproduzieren \o/  (Ich bin mir sicher, das ich beim ersten Versuch zur Klärung das ganze nur zu dilettantisch übermittelt hatte, sonst hatte das sicher auch schon vorher geklappt). 

Zur Lösung müssen wir hier wohl mit irgendwelchen Herstellen Hand in Hand arbeiten und an gewissen Stellen aktiv werden. Ich kann mir vorstellen, dass ihr es ganz genau wissen wollt, ich war aber erst mal happy, das ich überhaupt was vermelden kann, daher wollte ich die Kollegen auch nicht mit vielen weiteren Fragen nerven Ich vermute mal, das an irgendeiner Stelle der Hersteller eines Netzelements /Servers / whatever irgendwas patchen oder updaten oder einfach nur neu konfigurieren muss, daran wird jetzt aber gearbeitet.

Da ich jetzt weiß, wen ich fragen muss, kann ich versuchen an detaillierte Infos zu kommen, ich möchte aber nichts versprechen, seht es mir nach 

Beste Grüße und einen schönen zweiten Advent morgen \o/

Matze