Jein.
To inform clients possessing a valid DHCP release about a gateway change (the link quality to the gateway could have dropped or the client is roaming around) batman-adv will also inspect incoming DHCP renewal packets. If their destination is not the currently selected gateway and below a certain TQ threshold (currently defaulting to a TQ of 50), the DHCP renewal packet is not forwarded, thereby forcing the client to request a new DHCP lease from a better connected gateway.
Ganz raus hält sich batman_adv leider nicht; und ohne Gateway-Modus kamen hier zumindest (v14) gar keine DHCP-Pakete durch. Aus meiner Sicht wäre ein DHCP-transparenter batman_adv-Modus wünscheswert für Gluon-Netze, aber nunja. Vielleicht in v18 
D. h. Ihr announced nur ein /64 lokal von den Knoten per RA? Bekommen, und behalten, dann nicht alle Clients zumindest überwiegend (laufzeitbedingt) den initialen Knoten als v6-Default-GW bis zum Ende der v6-Adressen-Gültigkeit (die nur per FW-Update geändert werden kann)?
Inter-GW-Traffic ist zwar doof, aber verkraftbar (insbes. ohne künstliche Nadelöhre wie fastd). Inter-Knoten-Traffic (Client-Knoten-GW-GW-Knoten; Rückweg sollte dann direkter gehen?) ist doch aber bei VPN-Verbindungen eher richtig kacke?
Nach den Erfahrungen mit v4 bin ich eigentlich ganz froh, daß batman_adv (zumindest in v14) v6 ignoriert. Wie so oft, abschaltbare Features verbreitern das Anwendungsspektrum. Nur wie man public v6 »richtig« in ein Gluon-Mesh einführt, ist mir noch immer unklar.