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? 

Mijn KPN Box 12 (Sagemcom F@ST 5359, glasvezel) levert multicast IPv6 Router Advertisements van een ander apparaat op het LAN wél af aan bekabelde clients, maar níet aan wifi-clients.

Situatie: ik draai Home Assistant met een OpenThread Border Router (voor Matter/Thread smart home-apparaten). Die adverteert volgens de standaard (RFC 4191) periodiek een route naar het Thread-netwerk via multicast RA's op het LAN.

Wat ik met packet captures (tcpdump op het LAN + Wireshark) heb vastgesteld:

• De RA's worden correct op het netwerk gezet en komen aan bij bekabelde clients.
• Wifi-clients (Android-telefoon) ontvangen ze niet: de telefoon installeert de route nooit en kan het Thread-netwerk niet bereiken.
• Direct na een wifi-reconnect komt de RA (als antwoord op de Router Solicitation van de telefoon) wél door — daarna werkt alles, totdat de route na 30 minuten verloopt.

Gevolg: het toevoegen van Matter-over-Thread-apparaten via een telefoon blijft eindeloos hangen op "controleren van verbinding met Thread-netwerk". Workaround is telkens wifi uit/aan zetten vóór het koppelen — niet echt werkbaar.

Dit lijkt op een multicast-filterprobleem (MLD snooping?) in de wifi van de Box 12. Er zijn geen instellingen in de Box 12 om dit aan te passen.

Vraag: kan dit intern worden uitgezocht / als bug worden gemeld richting Sagemcom? Packet captures kan ik aanleveren. Met steeds meer Matter/Thread-apparaten in huishoudens gaat dit meer KPN-klanten raken.

Het onderwerp van dit topic ging over router advertisements die naar ff02::1 gestuurd werden als antwoord op een router solicitatie. Dit lijkt veranderd te zijn in versie V10.C26.06.10, daar gaan router advertisements op verzoek terug naar de indiener.

 Unsolicited: IP6 fe80::b2ac:d2ff:fe57:410d > ff02::1: ICMP6, router advertisement, length 104

Solicited: IP6 fe80::b2ac:d2ff:fe57:410d > fe80::221:6bff:fea0:8d4a: ICMP6, router advertisement, length 104

Ik het het met “radvd” voor elkaar een extra route van wifi naar wifi te sturen, als ik de gelegenheid heb zal ik het bedraad proberen.  Ik krijg alleen een extra default route die me niet bevalt, dat moet ik nakijken. Gelukkig een hogere metric. 

Maar hoe moet ik dat zien als alleen bij herstarten van Wifi de verbinding werkt? Stuurt Android een router sollicitation,  en krijgt een rechtstreekse advertisement terug. Luistert Android dan alleen naar unsollicited advertisements die blijkbaar niet aankomen en gooit de route eruit als de tijd op is ?  En stuurt geen nieuwe solicitation? 

Ik zit nog even te denken: is het niet logischer om prefix delegatie te gebruiken? 

Helaas is de KPN implementatie nog steeds niet op orde, maar als je de home assistant de op dit moment enige prefix ff00 laat opvragen heb je  het ff00:/56 subnet netjes gerouteerd naar de home assistant vanuit de KPN router en daar dus een apart netwerk voor beschikbaar. Dat gaat dan vanuit Android via het normale 0::/64  netwerk naar de router en vandaar naar de home assistant. 

Een update: ik kan niet reproduceren op de V10 met actuele software router advertisements niet doorlaat. Er is nog wel iets aan de hand: ik heb eerst het subnet 2000::/64 geadverteerd. Dat is een globale prefix, dus eigenlijk niet goed. De route wordt netjes ingesteld naar de server, maar geen verbinding. Tot mijn verbazing toont traceroute de router als eerste tussenstation en het internet op. In de router is de verbinding tussen Lan en Wifi dus geen pure bridge, maar komen de plaketten onderweg een route tegen die naar het internet loopt. Daarna heb ik fd00::/64 geadverteerd, die geeft wel een directe router naar de server en ik kan een webpagina vanuit Linux wifi, iphone6 en Samsung A26 bereiken.  Ik kom met Linux alleen niet van die extra default route af. 

ip -6 route | grep b7b8
fd00::/64 via fe80::5e02:5c65:afed:b7b8 dev wls1 proto ra metric 600 pref medium
default via fe80::5e02:5c65:afed:b7b8 dev wls1 proto ra metric 601 pref medium

Als ik op de server een gedelegeerde prefix zet, dan is de server zonder verdere poespas te bereiken via Wifi (en evt. van buiten) . Maar ik ken de systemen niet, dus ik weet niet of dat allemaal past binnen het IOT concept. De HomeAssistent is een Linux systeem, het mooiste zou zijn als die met twee ethernet interfaces is uitgerust, of een Wifi interface als alleen Wifi voldoende is, dan kan evt. via een omgekeerde firewall het hele IOT netwerk gescheiden worden van de rest, en eventueel naar huis bellen voorkomen worden.

Dus: een V10 met actuele software laat router advertisements passeren, maar het is niet gegarandeerd dat ieder willekeurig IPv6 adres zich tussen LAN en Wifi laat versturen.

NDP payload len 40, from addr: fe80::5e02:5c65:afed:b7b8, iface: wls1
  Type: RA
  Hop limit: 64
  Managed address configuration: no
  Other configuration: no
  Default router preference: medium
  Router lifetime: 60s
  Reachable time: unspecified
  Retransmit time: unspecified
  Source linkaddr: 18:31:bf:09:74:72
  Route: fd00::/64, lifetime: 30s, preference: medium