Waarom worden router advertisements als antwoord op router solicitations naar “Alle hosts” gestuurd i.p.v. alleen de aanvrager?

Een RA (Router Advertisement) is een multicast message en wordt verzonden aan multicast IPv6 adressen ff02::, de voorbeelden zijn

• ff02::1 - alle apparaten
• ff02::2 - alle routers
• ff02::5 - alle OSPFv3 routers
• ff02::a - alle EIGRP (IPv6) routers
• ff02::1:ff00::/104 - het aangevraagde apparaat

Een RA wordt periodiek verzonden, maar na een ontvangen van een RS (Router Solicitation) wordt een RA meteen verstuurd. In tegendeel tot RA is NA (Neighbor Advertisement) het antwoord op een NS (Neighbor Solicitation) een unicast message.

De reden voor het gebruiken van lokale adressen dat deze moeten altijd geldig zijn (ook zonder internet), deze zijn vergelijkbare met private adressen van IPv4.

Bedankt, @TDN.  

Ik heb zojuist even een kale box 12 getest, en er komt inderdaad alleen een lokaal adres uit. Het zou mooi zijn als er een mogelijkheid komt een handmatige naam ↔ adres mapping te maken voor deze adressen zodat een systeem ook een AAAA record in DNS krijgt, ik ben erg slecht in IPv6 adressen onthouden. Alle camera’s kunnen dus via IPv6 met een NAS blijven communiceren als het internet wegvalt.  Ik heb nooit problemen met die adressen gehad, ze zitten niet in de weg, maken het alleen wat minder overzichtelijk. 

De OPNsense router kan router advertisement aanmaken via “radvd” of “dnsmasq” . Even op Linux getest, dnsmasq beantwoordt een router solicitation naar ff02::1, radvd heeft wat meer opties en valt niet het hele netwerk lastig met antwoorden op router solicitations:

 10:56:41.043865 IP6 fe80::2e44:fdff:fe89:99b8 > ff02::2: ICMP6, router solicitation, length 8
10:56:41.045104 IP6 fe80::8ffd:adfa:5c8c:357e > fe80::2e44:fdff:fe89:99b8: ICMP6, router advertisement, length 96

Het kan dus allebei, ik heb begrepen dat de unicast optie in een omgeving met mobieltjes de voorkeur heeft om ze niet iedere keer uit de slaaptoestand te halen. 

Veelal zijn dit soort dingen ook gewoon hoe netwerkprotocollen nou eenmaal werken. Maar, ik ben zelf hier ook niet in die mate mee bekend dat ik zo kan meepraten. Het lijkt alsof TDN je vraag beantwoord heeft. Als je nog wel (aanvullende) vragen hebt, geef het aan. Dan kan ik ze altijd stellen intern.

TDN heeft de vraag betreffende de “fd” adressen duidelijk beantwoord.

De andere vragen hebben te maken met het feit dat steeds bij problemen “Zet IPv6 uit” de workaround is.

Waarom?  Alle informatie nodig voor IPv6 autoconfiguratie wordt correct geleverd. 

Kunnen de timings een invloed hebben? Die zijn kort bij IPv6. De DIW box meldt zich iedere twee uur bij de V4 DHCP server, dat is genoeg. 

De IPv6 DNS server instelling heeft 60 seconden levensduur, wat vreemd is want die verandert alleen als de DNS instellingen aangepast worden. Dit veroorzaakt een hoop nodeloze drukte op het netwerk… Maar geen idee of dat een rol speelt, de meeste problemen zijn met Android en als gebruiker heb je weinig mogelijkheden om daar onder de motorkap te kijken. 

Als ik tijd heb, zou ik de KPN modem met IPv6 weer aansluiten en een stuk verkeer luisteren naar ICMPv6. Maar princiepiel is eenvoudig voor Android te fixen. Android tot v14 ondersteunt alleen SLAAC, vanaf v14 DHCPv6 stateless. De radvd.conf voor gebruik met Android

# radvd.conf - enable SLAAC in addition to DHCPv6
interface wlan0 {
    AdvSendAdvert on;
    AdvManagedFlag off;    # M=0, SLAAC preferred
    AdvOtherConfigFlag on; # O=1, Stateless DHCPv6, DNS/NTP from DHCPv6
    prefix ::/64 {
        AdvOnLink on;
        AdvAutonomous on;  # SLAAC enabled
    };
};

Dit is idd heel kort, de standaard instelling is 10 minuten.

De router solicitatie die uit deze radvd.conf komt is in principe gelijk, behalve:

• Router preference: high bij KPN. 
• De tijden valid/pref tijden zijn 86400/14400. Bij KPN 86400/7200, maar voor het extra  fd5a subnet 900/300. Waarom die zo kort zijn weet ik niet.  
• Router lifetime 1800, bij KPN 180.
• Herhaling Unsolicited: Radvd default tussen 200 en 600 sec, bij KPN tussen 30 en 60 seconden. 
• Wat bij KPN toegevoegd is is de Recursive DNS server met een levensduur van maar 60 seconden.

radvd in bovenstaande configuratie beantwoordt router solicitations naar het adres van de aanvrager, dus niet naar “alle hosts”, dat is ook een verschil met de KPN software. 

Zonder DNS in de RA komt de DNS server dus uit de DHCPv4 server in oude Android, en uit DHCPv6 in de nieuwe. DHCPv6 staat aan in de KPN software voor zover het “Information request” betreft, dus ook dat is OK (in alle drie standen van IPv6 prefix delegatie)

Alles lijkt binnen specs, alleen het DNS interval is veel korter dan geadviseerd in de radvd manpage, het zou 300 moeten zijn. 

Dus…. wat veroorzaakt het falen van sommige Androids? Timings, overdaad aan router advertisements, of toch een brakke IPv6  implementatie bij sommige merken ???  

Nog even getest met 2 maal Linux, Win10 en TV+/AndroidTV op het netwerk:

Alleen Linux maakt zich druk over de 60 seconden levensduur van de DNS parameter en stuurt router solicitations. Windows en Android TV gebruiken dus mogelijk alleen de IPv4/DHCP DNS of de DHCPv6 DNS, waar helemaal geen timeout op zit.

De reguliere “unsolicited” router advertisemens zetten alle tellers weer terug op de oorspronkelijke waarde.  De timings zijn dus niet echt belangrijk, zolang alle router advertisements aankomen en verwerkt worden. Dus toch de implementatie op specifieke Android telefoons?  Privacy extensies, tijdelijke adressen en slaaptoestand?