Linuxový démon radvd má skutečně výchozí hodnotu pro RA rovnou 600 sekund a je to tak právě kvůli spoření baterií u mobilních zařízení. To je ale známá věc, to pánové neobjevili nic nového. A zároveň takto dlouhý čas není vůbec problém, protože nově připojené zařízení samo posílá do sítě zprávu Router Solicitation (RS) a router tím aktivně vyzve k předání informací.
Android bohužel posílá leda hovno a ne RS. V rámci spoření baterky. A právě proto lidé nastavují routery na podobné šílené hodnoty. Jinými slovy - soudruzi v Googlu by si měli místo "rad" radši zamést před vlastním prahem a opravit si totálně rozbité IPv6.
https://code.google.com/p/android/issues/detail?id=79576
https://code.google.com/p/android/issues/detail?id=32662
Tady jde ale o trochu něco jiného. Pokud zařízení vyzve pomocí RS router o informace, router zašle RA. Tato zpráva je nicméně zaslaná na multicast adresu "všechny-uzly-v-síti". Díky tomu, že je to multicast pro všechny, každé zařízení to musí zpracovat, i když mu je to třeba jedno.
Co je na daném standardu to podstatné, není ani tak interval s jakým se posílá RA, ale to, že se nevrhuje, aby RA, zaslané jako odpověď na RS bylo zaslané jako unicast. Tedy pouze tomu, kdo se ptal. Eliminuje se tedy otravování ostatních.
To je ale prakticky realizovatelné na drátových sítích, ale ne na WiFi viz.:
http://www.root.cz/clanky/bezpecne-ipv6-trable-s-multicastem/, odstavec "Multicast a WiFi".
Musi a nemusi, ze ... pokud nechci dostavat RA, tak ze z ty skupiny proste vyhodim. Coz narozdil od zminenyho DHCP a broadcastu lze. A pokud se bavime o wifi, je to stejne jedno, protoze automaticky vidim veskery provoz na te wifi a je prave ukolem wifiny aby si vybirala pakety, urcene pro ni => musi byt zapnuta. A pak uz to, ze zpracuje RA je 0,00000 prd, protoze zdaleka nejvetsi spotrebu ma radio.
Takze se tu resi naprosto neexistujici problem.