Some of you may have read my confusing posts over the past week or so detailing a problem where an IPv6 ULA network that I did not define (and cannot be found _anywhere_ on my router) is polluting my network.

As it turns out, I wasn't imagining it, and now that I have a proper dump and understand the problem, I'm not the only one, either.

If you are running dual-stack and have a Nest Thermostat or a Nest Protect in your home, odds are, you're seeing it too.

For reasons that Nest is currently unable to explain, the Nest devices are sending out Router Advertisements on the Ethernet segment for their own ULA network, with a preference of 0 and a client lifetime of 7200 seconds...ad infinitum.

I can clearly see this happening in my capture (as have two others, thus far).  The question is, what sort of firewall rule can I craft on my router that allows it to block these RAs before they can reach my clients?  (In effect, I'd like to configure the router with one general rule that essentially says "if the RA didn't originate here, drop it.)

Is this even possible?

Rodney

(Last edited by rhester72 on 23 Nov 2014, 05:06)

Had to go all the way to Nest Engineering on this one.

tl;dr It isn't a problem, ignore it and leave it alone.

Longer explanation:

Nest products work on the concept of intercommunication - in short, all Nests (thermostats and smoke/CO detectors) "talk" over WiFi, both over the Internet (status, remote control, weather, etc.) and your local intranet (coordination of alerting, away detection, etc.).

Nest engineers tried to solve for the following:

- Intercommunication should be as fault-tolerant as possible, and still function for emergency service (i.e. multi-room alarms simultaneously) for as long as they can even with complete loss of Internet service
- The transport should be as non-disruptive to customer networks as possible

Their solution was to build their own IPv6 ULA network riding on your WiFi.  The first device to be powered up randomly generates (and stores) a ULA prefix and begins advertising it over your local network.  Other Nest devices, once powered on, will receive the RA from the first Nest and join that same local network for intercommunication.  In the event an RA is not received by a Nest device in two hours, the remaining interconnected devices will hold an "election" and another will take over the role of doing RA broadcasts.

The thinking was that since IPv6 has received such low adoption in the home at this time, doing this would be least visible to customers while still achieving the desired goals.  In addition, they realized the potential for communication disruption, so they further set the preferred_lft to zero (which is ignored by Nest devices, as they will continue to communicate over this ULA network, but honored by other clients, so they will never attempt to use that network).  It would have been suicide to build a DHCPv6 server into Nest devices (how would non-Nest clients deal with that?), and there's unfortunately no way of issuing an RA broadcast that says "please only pay attention to this if you are a Nest device", so non-Nest clients (i.e. Windows, Android, etc.) will necessarily get an address on the private Nest ULA network, despite firewall rules on the Nests themselves preventing any meaningful communication with them (and they are pretty extensive, up to and including not responding to more than one ping per minute from any given host).

For this reason, it would be a pretty bad idea to block these RAs at the router level, since they would prevent Nest intercommunication in the event one of the devices is restarted for some reason.  The network is as self-contained as it can be and will never be used by non-Nest clients, so it's completely harmless and quite necessary for their solution.

I'm reasonably confident at this point that the other person who similarly observed a "mystery ULA network" on their LAN also has one or more Nest devices in their home.

Hope this helps someone!

Rodney