Hallo Leute!
Kaum habe ich gejubelt, dass ich doch ein /56-Subnet bei der Telekom habe, und jetzt kommen die nächste Probleme...
Also, ich habe jetzt an dem Gateway eine Schnittstelle server0 mit einer IPv6-Adresse. Nun richte ich Dibbler, den ich nutze um die IPv6 überall zu verteilen. Der neue Abschnitt ist:
iface "server0" {
prefered-lifetime 3600 valid-lifetime 7200
# assign addresses from this pool class { pool 2003:c2:7f14:3c10:1::/64 }
# provide DNS server location to the clients option dns-server 2003:c2:7f14:3c10:1::1
# provide their domain name option domain srv.lucabert.intra
client duid 0x0001000123f81067dc9c5216f683 { address 2003:c2:7f14:3c10:1::11 } }
Dibbler neugestartet und auf dem Server auf gestartet. Nun hat der Server auch seine IPv6-Adresse, aber irgendwie geht es nicht, denn es ist sogar vom Gateway nicht anpingbar... Mit tcpdump sehe ich:
13:41:37.717806 IP6 2003:c2:7f14:3c10:1::1 > ff02::1:ff00:11: ICMP6, neighbor solicitation, who has 2003:c2:7f14:3c10:1::11, length 32 13:41:37.718538 IP6 2003:c2:7f14:3c10:1::11 > 2003:c2:7f14:3c10:1::1: ICMP6, neighbor advertisement, tgt is 2003:c2:7f14:3c10:1::11, length 32
Kann jemand mir sagen, was ich falsch mache?
Danke Luca Bertoncello (lucabert@lucabert.de)
On Thu, Feb 14, 2019 at 1:45 PM Luca Bertoncello lucabert@lucabert.de wrote:
Mit tcpdump sehe ich:
13:41:37.717806 IP6 2003:c2:7f14:3c10:1::1 > ff02::1:ff00:11: ICMP6, neighbor solicitation, who has 2003:c2:7f14:3c10:1::11, length 32 13:41:37.718538 IP6 2003:c2:7f14:3c10:1::11 > 2003:c2:7f14:3c10:1::1: ICMP6, neighbor advertisement, tgt is 2003:c2:7f14:3c10:1::11, length 32
Kann jemand mir sagen, was ich falsch mache?
Was sagt
$ ip -6 a
auf den beteiligten Kisten?
Es sieht so aus, daß er die Link-Local Adresse von 2003:c2:7f14:3c10:1::11 nicht auflösen kann. neighbor solicitation/advertisement ist gut auf https://www.ipsidixit.net/2010/03/24/239/ beschrieben.
(Man soll den zweiten Schritt nicht vor dem ersten tun.) Ich empfehle, zuerst den radvd zwecks SLAAC Richtung Innenseite in die Gänge zu bringen. Und, nicht vergessen, dem Router das Routen auch zu erlauben ("net.ipv6.conf.all.forwarding = 1").
DHCPv6 kannst Du optional dann immer noch draufsetzen, z.B. wenn Du einzelne Adressen menschenmerkbar festnageln oder Präfixe weiterdelegieren willst.
Am 14.02.2019 15:01, schrieb William Epler:
Was sagt
$ ip -6 a
auf den beteiligten Kisten?
Ich glaube, ich habe die Ursache des Problems gefunden, allerdings noch nicht die Lösung... Auf dem Server ist die IPv6 mit Netmask /128 statt /64. Ändere ich manuell die IP, mit dem richtigen Mask, dann geht alles.
Nun ist die Frage, warum die Mask falsch ist... Ideen?
Danke Luca Bertoncello (lucabert@lucabert.de)
On Thu, Feb 14, 2019 at 3:06 PM Luca Bertoncello lucabert@lucabert.de wrote:
Ich glaube, ich habe die Ursache des Problems gefunden, allerdings noch nicht die Lösung... Auf dem Server ist die IPv6 mit Netmask /128 statt /64. Ändere ich manuell die IP, mit dem richtigen Mask, dann geht alles.
Vergiß hier einfach, was Du über IPv4 gelernt hast und setze den Präfix eines jeden Interfaces auf /64
Nun ist die Frage, warum die Mask falsch ist...
RFC5375 Die Netzmaske am Interface muß per Definition *immer* /64 sein, damit Automatismen wie neighbor solicitation/advertisement oder SLAAC funktionieren. Ansonsten ist Handarbeit angesagt, s.a. https://www.ipsidixit.net/2010/03/24/239/
Delegieren/strukturieren/routen kannst Du im Fall Telekom mit Präfixen von /57 bis /63
Am 14.02.2019 15:20, schrieb William Epler:
On Thu, Feb 14, 2019 at 3:06 PM Luca Bertoncello lucabert@lucabert.de wrote:
Ich glaube, ich habe die Ursache des Problems gefunden, allerdings noch nicht die Lösung... Auf dem Server ist die IPv6 mit Netmask /128 statt /64. Ändere ich manuell die IP, mit dem richtigen Mask, dann geht alles.
Vergiß hier einfach, was Du über IPv4 gelernt hast und setze den Präfix eines jeden Interfaces auf /64
Ja, ich weiß! Der /128-Präfix hat Dibbler gesetzt. Und das habe ich auch als falsch erkannt. Die Frage ist aber, WARUM Dibbler /128 nutzt, statt /64...
Ideen?
Danke Luca Bertoncello (lucabert@lucabert.de)
On Thu, Feb 14, 2019 at 3:30 PM Luca Bertoncello lucabert@lucabert.de wrote:
Ja, ich weiß! Der /128-Präfix hat Dibbler gesetzt. Und das habe ich auch als falsch erkannt. Die Frage ist aber, WARUM Dibbler /128 nutzt, statt /64...
Ideen?
http://klub.com.pl/bugzilla3/show_bug.cgi?id=222
Am 14.02.2019 15:43, schrieb William Epler:
On Thu, Feb 14, 2019 at 3:30 PM Luca Bertoncello lucabert@lucabert.de wrote:
Ja, ich weiß! Der /128-Präfix hat Dibbler gesetzt. Und das habe ich auch als falsch erkannt. Die Frage ist aber, WARUM Dibbler /128 nutzt, statt /64...
Ideen?
Verzeihung, vielleicht bin ich einfach zu dumm dafür, aber ich verstehe nicht, warum dieses Bug mich betreffen soll... Ich __WILL__ ein /64-Präfix vergeben, und ich denke ich habe Dibbler auch so eingerichtet, allerdings geht das nicht...
Danke Luca Bertoncello (lucabert@lucabert.de)
Am 14.02.2019 13:42, schrieb Luca Bertoncello:
Kaum habe ich gejubelt, dass ich doch ein /56-Subnet bei der Telekom habe, und jetzt kommen die nächste Probleme...
So, ich habe das Problem gefunden und zwar, es ist ein Bug in der Version, die mit Debian 9 kommt (1.0.1). Ich habe die selbe Version, die ich auf Debian 8 habe (0.8.2), installiert und sofort funktioniert alles...
Na toll...
Grüße Luca Bertoncello (lucabert@lucabert.de)
lug-dd@mailman.schlittermann.de