Es ging ja um sauber + nsupdate.
Was genau meinst Du mit "sauber"?
Ohne auch alles andere zu verdrehen.
Fritz!Box-Standardeinstellungen plus DHCPv4 lease reservations plus Dein nsupdate reicht.
Dann nutzt Du alleine ein anderes SLAAC als in RFC 4862 beschrieben.
denn die FritzBox bekommt die IPv6-Adressenkonfiguration des IPv6-Clienten mit slaac sofort und einwandfrei (z. B. nach einem restart des dhcpcd) mit.
Ja, durch Raten.
Über DHCP
v4 findet folgendes statt:
- DHCPDISCOVER: Ein Client ohne IP-Adresse sendet eine Broadcast-Anfrage nach Adress-Angeboten an alle DHCP-Server im lokalen Netz.
- DHCPOFFER: Die DHCP-Server antworten mit entsprechenden Werten auf eine DHCPDISCOVER-Anfrage.
- DHCPREQUEST: Der Client fordert eine der angebotenen IP-Adressen, weitere Daten sowie Verlängerung der Lease-Zeit von einem der antwortenden DHCP-Server.
- DHCPACK: Bestätigung des DHCP-Servers zu einer DHCPREQUEST-Anforderung oder die Übermittlung von Konfigurationsparametern, die vorher durch DHCPINFORM vom Client angefordert wurden.
- DHCPNAK: Ablehnung einer DHCPREQUEST-Anforderung durch den DHCP-Server.
- DHCPDECLINE: Ablehnung durch den Client, da die IP-Adresse schon verwendet wird.
- DHCPRELEASE: Der Client gibt die eigene Konfiguration frei, damit die Parameter wieder für andere Clients zur Verfügung stehen.
- DHCPINFORM: Anfrage eines Clients nach weiteren Konfigurationsparametern, z. B. weil der Client eine statische IP-Adresse besitzt.
(Fett markiert das, was im Idealfall wirklich stattfindet)
In diesem einen Moment kriegt die Fritz!Box ein Lebenszeichen vom Client mit HWAddr X und auch wenn das Lebenszeichen an sich lediglich IPv4 betrifft:
Da sie weiß, wie eine SLAAC-Adresse ohne Privacy Extensions generiert wird und weil sie ein Präfix advertised hat und weil sie in diesem Moment die HWAddr des Clients kennt und weil sie weiß, daß der Client sich gerade konfiguriert,
kann sie in diesem Moment spekulieren, daß der Client sich eine solche Adresse erzeugt haben könnte. Diese Adresse kann sie dann verifizieren und das macht z.B. auch DNSMasq so.
Das ist aber nur ein Versuch auf blauen Dunst, denn mit Privacy Extensions kann sie die Adresse eben
nicht spekulativ ermitteln.
Daß ich Recht habe wirst Du feststellen, wenn Du den Client mal aus Jux IPv6-only konfigurierst, also DHCPv4 auf dem Client deaktivierst.
Diese vom IPv6-Client konfigurierten IPv6-Adressen sind im Heimnetz (Details) der FritzBox, bei IPv6-Adressen auch sofort eingetragen. ...
Ja, s.o.
und es findet auch laufend IPv6-Traffic zwischen der FritzBox und dem IPv6-Client, über diese IPv6-Adressen statt.
Den scheint die Fritz!Box nicht zur weiteren Analyse/Bestätigung heranzuziehen.
Das würde vermutlich auch das LAN tierisch bremsen.
Die Fritz!Box bewertet nur den Traffic, der das LAN verläßt. Regelmäßige IPv6-Pings des Clients auf Google z.B. beleben die IPv6-Namensauflösung ebenfalls wieder.
Warum ist da dann dieser Unterschied (... d. h. namensauflösung ja oder nein), zwischen IPv6-Adressen die per avahi/mDNS seitens der FritzBox zur Kenntnis genommen worden sind und den IPv6-Adressen, die die FritzBox durch "raten" sofort (siehe z. B. den dump verursacht durch ein "sudo systemctl restart dhcpcd")) zur Kenntnis genommen hat?
Unabhängig von mDNS ja oder nein kann die Fritz!Box bei Auftreten von DHCP(v4)-Ereignissen
immer einen Rateversuch starten:
Direkt nach dem Start eines Clients funktioniert die IPv6-Namensauflösung also immer, solange auf ihm auch noch IPv4 aktiv ist
und er DHCPv4 zur Konfiguration von IPv4 nutzt, denn das ist der Trigger-Event für's Raten.
Im Gegensatz zu DNSMasq vertraut die Fritz!Box aber nicht darauf, daß der Client diese SLAAC-IPv6 dauerhaft behält und will gelegentliche Bestätigung.
mDNS und llmnr bieten diese Bestätigung zuverlässig und ohne großen Zusatzaufwand und eben sogar dann, wenn der Client Bullshit Extensions benutzt.
Traffic ist die zweite Möglichkeit, die aber eben nur dann funktioniert, wenn der Client genug aus-/eingehenden Traffic verursacht (Das große Handicap z.B. bei meinen E2-Receivern, die verursachen nur extrem selten Internet-Traffic).
Die Fritz!Box könnte natürlich bei Clients ohne Privacy Extensions auch einfach darauf vertrauen, daß sie diese IPv6 zumindest zwischen zwei DHCPv4 leases behalten, so wie es DNSMasq macht.
Warum sie das nicht tut mußt Du aber AVM fragen.
